So Dion can you tell us where yourself in, what you're up to?

Sure Floyd, so we worked together on theserverside.com which is an enterprise portal and that's were we focused more on the whole server side piece and the Java community in general; these days I'm actually the co-founder of a site called ajaxian.com, which focuses on the Ajax technology. And I work on that with a friend called Ben Galbraith and we have different training and consulting and items like that, and then I'm focusing on real kind of project work within Ajax, still focusing on Java on the backend and also doing a lot of Ruby these days.

So why did you move into Ajax, what's so exciting about it?

So the reason we got into Ajax it's actually kind of funny, we were giving a presentation that had nothing to do with Ajax and the titles that had not been coined yet. There was just called "Creating Killer web Applications" and offline cable applications. And we gave this presentation, which we gave it a few times, and people were interested, people came to the talk, but then the Ajax term was coined and we had to go through and do search replaces on our presentation, and then all of a sudden we had masses of people coming in, and we quickly found that there wasn't a really good place for resources, they were kind of old resources, you know Microsoft has it set, because really Ajax is kind of DHTML, but just with a different name, and based on that we thought "Oh, we should set up a little blog to talk about it". And then it got to be more and more popular, it just kind of exploded and that's where ajaxian com kind of came up from.

What is Ajax going to bring to the world? What's new now? What's possible?

So I think Ajax totally changes things in quite a few ways. The key to me is that a lot of people focus on Ajax as the technologies behind it, so they think "Ah, Ajax, asynchronous Java Script and XML, technology is great," but that's not what I think is cool about Ajax. I think what's cool about Ajax is that we totally change our web architectures. So now we think about the Web 1.0, although I think it's hilarious to put a version number to the web which changes every second, but, anyway the traditional web we have very, very, simple request responses, that were very very course grained.pages loaded all the time. And that's great for doing HTTP and for retrieving the documents, which is of course what HTTP was invented for, what the web kind of came about for, but the problem is you can't build rich web applications that way. So if you think about it and you were building a swing, GUI or WinForm application and every time you change the little widget it redrew all the others widgets on the screen you would think that was a crazy architecture, but that's all we had to go with on the Web 1.0. So with Web 2.0, and using Ajax specifically within it, we get around that problem, we don't have to go back to the server and download the entire UI for every little thing that we do, we can make these asynchronies requests back to the server, get something back and then maybe tweak a little piece that's going on within our application and that totally changes the way in which we can build these apps, we can do a lot more rich user interfaces and we can do just very simple things that make a lot more sense. And so we see a lot of these little ideas little use cases that really make sense just kick off, you don't want to redraw the page you just want to tell the server something, you want to change a little piece on the server, and this is where Ajax is kind of revolutionizing the web.

So you mentioned what's possible what kind of tools do you need to make this work?

So we should kind of split up what these Ajax tool kits are, because everyone comes up and says they "support" Ajax, they have Ajax tools, and what does that really mean? It doesn't mean anything. So we kind of split this up and we have different layers within the Ajax landscape, and the very low layer is what the browsers give you for remoting so that's XML, HTTP requests which are called XHR because it's shorter, and IFrames and different ways to talk back and then the kind of first Ajax framework set above that layer and give you a cleaner API to talk back. So what we're talking about here, a framework called the Dojo toolkit, Prototype is another one, these guys that kind of wrap around that remoting, and this is really important. We actually did a survey on Ajaxian and 75% said that they don't use any toolkits, they just go and write the raw XHR code and that' crazy to me because you run across tons and tons of browser compatibilities issues if you do that. For example, if you have get requests in your Ajax request, in IE it goes to the cache so suddenly I'm going back and hitting the server but it's returning the same thing every time. First time you do that you kind of hunt us all down, even getting the XHR object itself is different in different browsers, so for Internet Explorer you have to go for these com objects, which luckily Microsoft is changing with IE 7. In IE 7 it's going to be like in Mozilla or Safari with a native Java Script object and you can just say new XHR request and you're good. But apart from that, what if the browser doesn't support XHR? Well these remoting tool kits can sit above that and they can detect that, and they can do things like automatically correct a hidden IFrame and use that to do the transport mechanism. So it's giving you a higher abstraction to talk through to the backend server using kind of Ajax techniques. So that's kind of the remoting layer on top of that you have the UI layer, and the UI layer is just as it sounds consisting of little widgets and things that kind of sit on the application and talk back to the server. So, you know, people kind of argue about what this should be, some people think it should look like a desktop application, so you have windows and everything that looks like your operating system and others think it should just be more webby, be like google suggest little boxes and things like this and that's open to debate, but you're going to have those tool kits to do the UI and then on top of the you have ajaxian kind of web frameworks so we can talk a little bit more about that later

So tell us a little about the JavaScripts frameworks, how do they work and what is the best one out there?

Yes, so I mentioned the Dojo toolkit and Prototype and one of the things that those libraries do is that remoting layer, and we've already talked about the benefits there, but they also offer a lot more. So for example on the Dojo site it's a very mature, open source framework that gives you a whole set of packages, so if you're a Java guy you see these doc name space kind of looking packages. They give you the IO package which is to use for XHR Ajax request, gives you the graphics packages which allows you to do graphical effects, movements, and things like that, there's a whole widget API which allows you to build little reusable widgets and all you have to do then is actually use a HTML markup based language so this sounds more like XUL (pronounced 'zool') and XAML on the Microsoft side that allows you to just say div type equals or it's actually Dojo type equals editor and then Dojo automatically goes in and builds a very rich wysiwyg editor tool or kind of like a word based editor tool, so there's a whole notion of widgets.

There's also additions to the language itself, to JavaScript, so there's a Dojo.lang that gives you things like mix ins so if you're using languages like Ruby and the others like that, you'll like to mix in code from other objects and say "Hey, the code is in that object and that one, put them all together and allow me to have access to them right here. A lot of other language exceptions can go with it, one of the most important is actually the fact that JavaScript unfortunately doesn't have name spaces by default, so this means that you can get tons of collisions as you have different functions and things that are going on, anyone can rewrite those functions because JavaScript allows you to, anytime, add methods, take them away from an object or put them on to a type. So even if you have a thousand objects that are in the vm if I had the method foo to the type of var all of the objects instantaneously get that method added.

It's dangerous to not have these name spaces, so Dojo adds this name space routine so what you end up doing is that in different packages you say Dojo require the widget or whatever, Dojo require the XHR object. Whatever you need from within this large Dojo system you require and it only downloads the code you need on the fly right then so you don't have to download this massive library. Dojo has a whole bunch of these different kinds of name spaces, they cover everything. Another really cool one that you always end up using is the event package and what's cool about that is another one of the problems between IE and Firefox is the dom events are different in different areas.

Normally you have to write code so on Firefox it gets passed this event, on IE I have to get this event this way instead. And Dojo totally abstracts that away from you. And allows me to be able to say: Dojo connect to this dom element, to this node and if anything changes on that node run this function so I can do something dynamically. Even cooler than that you can do AOPsh stuff, you can say if this function ever gets code run this function as well so I can do stuff. So you can do JavaScript AOP and go really crazy. Then there's logging as well and things like that. Logging, what does that mean?

In JavaScript that means that instead of doing the alarm boxes to try and debug you have a little div in your application in debug mode and then as it goes through and different events happen you log out and they show up in that little div, so you can kind of capture what's going on. So that's you know just a few of the mirriad of name spaces that are out there for Dojo. A lot of people kind of think "ah, it's just a little Ajax thing", but it's a lot more and it's a lot of things you achieve wish you had in JavaScript. So then there's Prototype, and Prototype is a smaller framework and most people know it because it's coupled to Ruby on Rails, it's coupled from the stand point that Rails uses Prototype, it's not coupled from the standpoint that if you're writing Java you couldn't use Prototype. You can totally use it.

So Prototype has the same abstractions over XHR kind of things, it also has a bunch of effects, and it adds a lot of language things just like Dojo does in its module. So it actually looks very similar to Ruby in some things you can do so you can say: array dot each function and each element just like you do in Ruby. A lot of these things are kind of added, a lot of functions, it's all about making life easier for you. But then what everyone talks about is the $ function and so what that means is that JavaScript allows you to have a function literally named $, you couldn't do that in other languages and so you end up writing dollar sign open...the element id or actually even a node itself and it can only go and get a document element by id if it's a string that you past in and you can give multiple within that.

So it's kind of funny because it looks kind of Pearlish in some way because you got this 'dollar sign' function which makes shortcuts for everything. And then Prototype with these effects, there's another library called Scriptaculos that kind of add all these effects. The effects were put into Prototype first from this guy called Thomas Fuchs who kind of created Scriptaculos and the original prototype ones, and that's what you see all over the place with yellow fade techniques, things moving around, wobbling, and all these kind of crazy effects that are out there.

You never mentioned DWR, how come?

So DWR is more on the server side, in the standpoint of the other two technologies that I talked about are totally agnostic to the server side, they're all about JavaScript client programming. DWR, Direct Web Remotting, is a Java specific tool that allows you to do what we call some kind of proxy based Ajax. All we mean by that is if you use another proxy based technologies like EJB for example, well you have a stub object that you call methods on, it talks across the and calls the real object and calls the method over there.

DWR is doing exactly the same thing in fact but you're just getting JavaScript and you have a JavaScript object and you call a method on it, and it proxies it over using JSON, which is the JavaScript object notation and it talks over the wire to the web service or whatever is sitting on the server side in this case with DWR would be a Java service at the backend, marshals the information, calls the method on, even n a spring bean or any kind of object that you need to tie into, so you configure, so you go through and configure it, and then return values come back, it gets send back all the way to the JavaScript client.

So this is cool if you literally have a whole bunch of spring beans, servlets with methods and you just want to say: 'Hey, you know what, I need to expose this method and that method and I just want to be able to call it from my JavaScript client". DWR is perfect for doing that. It has some really cool utilities where by default you set it up, you turn it on, you go to /DWR where you put it into your web application, and it will tell you, in debug mode only for security, it will tell you all of the objects you are exposing, you can click on those objects and then it will show you all of the methods, allowing you to put in all the parameters, and send it right away there and it actually uses Ajax to talk back to the server master and show you the results.

So you can kind of poke and prod your module on the server side without writing a line of code yourself, DWR takes care of it. So if you're doing Java frameworks, you like the proxy based approach, DWR is the perfect way of doing the Ajax stuff, so the remoting layer piece it's not about the effects or anything like that, you'd use the other libraries for that piece but they can work together obviously so it's the beauty of putting these things together, but specially if you're using Spring, DWR is tightly integrated with Spring and it's a really, really great tool.

So moving on to the server side, you were talking about DWR what else is possible?

On the server side we have interesting debates coming up between the different types of framework so if we take Java for example, Java has just like we talked about the whole DWR, but if we think about the whole full frameworks, you've got the frameworks of the kind of the traditional struts webwork kind of style, and webwork which is now combining with Struts to be the new Struts, Struts Titanium, it actually embeds on top of Dojo, so you can have these webworks components, or Struts components whenever it's totally done, it will generate all the JavaScript and will do all this cool stuff for you.

So you end up not worrying as much about writing the JavaScript code, you're working on your server side objects, but it's in a very request response manner using actions like we're familiar with that kind of way doing MVC stuff. Then you have things like JFS and Tapestry and they are obviously very scented on component design. So the aim there is that in theory once we get down the road to have a component that's like the live suggest box, and you drag it across in creator, you drop it in, you set a few properties in the properties editor, and you don't even care that you're using Ajax, it's just a thing that may be in there. You grab a table and you do the checkbox of go ahead and make this live, and you can go back to it every five minutes to get new data.

And you're not even writing this code for you, it's in control of kind of generating that. Then you can even look slightly different again, you can look at something like Ruby on Rails and their approach, and they take an interesting approach because you can do many things, but they make it very, very, simple so when you talk to the server you obviously get some reply back and you have many choices for what gets returned.

You can get XML back and you can get that as a dom and you can work that dom and then do changes to your client side ui, you can get your own proprietary strings back and past them and do different things, you can get JavaScript back and then just do an eval so Google suggest actually does this, sends a request and all this JavaScript is thrown back to you and you evaluate it, which is nice and simple in many ways but you won't want to let anyone send JavaScript down for security reasons and such, but if you're in control that's no problem, and then there's the idea of just sending back HTML, and that comes back to Ruby on Rails, you get a piece of HTML, they call them partials, and then you're doing dot inner HTML and parse it in. So you go through with Prototype and you say "Hey I want to up data, this is the dom node I want to update, this is the..." this is some information about it if you need to tweak what's going on the Ajax side, it will hit the server, get the HTML, automatically inject that in the page.

So they're very much on, none of this JSON, none of this trying to marshal and call methods you just use web services that return some HTML and you render them. The nice approach for that is graceful failback is really easy with Rails because if Ajax doesn't work it doesn't matter your normal request don't go to this partial thing it returns it goes to the main request response to the full document. So it allows you to really degrade for the browsers that don't support JavaScript. Then there's Microsoft with Microsoft Atlas and Ajax.net that's more like this JSF module building these rich components that you can use, you can the build your own components, but if you're in a corporate IT kind of environment maybe you don't even care about writing them.

What browsers don't support JavaScript? Why do we need to care about that?

So you may not care about that but if you were blind and deaf maybe you would care about that. For example and so different government agencies have accessibility guidelines and we kind of tend to ignore on a lot of sites those issues. One of the side effects is when people put capchas within their forms and you have these images that spell something. I can see and I can barely read some of those, but if you're blind you can't see them.

Screen readers know how to do the web right now but they don't understand the Ajax world, so you end up writing those demographic off which is a shame and depend on what you're doing you're going have to make that call. You don't see a lot of people not enabling JavaScript anymore, that was a bit of a phase where people would turn that off, but I think so many of the sites are using it, and they are adding value. Before when there were spinning images and crazy things in JavaScript and rollovers, maybe you were like: 'that's a pain, I'm going to turn that off', but now you need it for the things so you turn it on so we don't see a big problem from that standpoint; you still have to cater to these different guys.

Again we've done some work for a lot of television situations where it has to work on all of these browsers, and some of the browsers don't support XHR for example and so then what do you do? Luckily some of the frameworks do great but some of them don't so you've got to make the call on what your audience is and who you want tell can't use your site.

What are some security issues with Ajax?

So there's actually a bunch of security issues and there's a bunch that are kind of totally taking care for you. We get asked a lot about 'what if I wanna do secure connections?' and I'm on my page that's secure but what about that Ajax request? Well Ajax uses exactly the same browser pipeline so you just open up your HTTPS and it's going to use the same pipeline. If you're authenticated it will send that already any cookies you have from that site they are going to automatically get sent.

So there you don't really have to worry about security in that kind of way that some people think you can. Then there's the whole kind of cross domain security, so am I allowed to just make an Ajax request a Google page and steal some headers, or get some information. Well actually Ajax doesn't allow you to do that it mandates that you talk back to your domain. If you use XML HTTP request that's the thing you have to use, unless you sign your JavaScript, and if you sign it digitally then your user can say: "Hey, ok, allow him to talk to other domains.", but if you're using it on the Internet that's crazy, you're not going make everyone every time you go there to say "Yes, this is ok" so there's a lot of work around in the community, a lot of people when they use those requests do different kind of hacks, they do things like automatically get access to the data they would create a dom node that is a script source equals that talks to the other side .

That then gets JavaScript back that you can access. There's a thing called JSONP. which is which is JSON with padding that kind of enables that even better, because rather than just get some JavaScript back you normally want to invoke something on that, so with JSONP you can say: "Hey go to the site and then call my callback with all of the stuff that came back from del.icio.us or Google or what have you. So there's the cross domain issues that by default you're locked out so you're kind of safe. Then there's one other security piece that is an issue and that is as we build these rich clients we find that there's people writing on their own that are using toolkits that allow you to do the whole rich client and the talk maybe using SQL to talk back to the server to talk to the database from the browser.

Now, if you think about that for a second that's scary because now I can just go through and change the JavaScript, I can even evaluate, I can go to a web page open up a little bar and evaluate the JavaScript in that context and I can just say: "open up the SQL code delete stuff from bla bla bla" and it's not right. So we have to think about although we can send back rich functionality we need our security border to still be at the server. So we need to have very discreet web services that we can talk to and that we can then secure rather then give in this rich very raw kind of user interface tool, that you can then say: "Oh yeah, do whatever you want, talk through to my database, then do it all in JavaScript", we have to think about those concerns, not only because we have it just in JavaScript like this but also because with Grease Monkey which allows me to inject into anyone's page, it's very very simple to go somewhere, if you see that happening I can just run my own script injected in the context of that site and that's scary.

So the notion of trust boundaries, brings up a question about what part of your application should live in Ajax line on the browser versus on the server? I mean if you put validation on the browser should you count on that for always happening? What guidelines over there?

Yes, that's great. Validation in my view is not the sexy thing about Ajax but it's the killer app of Ajax. If we think about what we've done with validation, originally we did it all on the server. And that works obviously, we can secure it, but that means that every time you fill out a form you have to go back to the server, and then even though they spend time filling out those other items they get one batch item back telling them what's wrong. So then we wrote JavaScript clients, JavaScript little pieces of code that did the validation, and then, great, we get to do it in line as you blur out a field it tells you if there's something wrong. But as you said we only relied on that, if someone turns of JavaScript no validation anymore.

With Ajax you get the best of both worlds, because you're able to put in JavaScript stuff and then go and invoke your server side logic. So you can have your validation logic in one place on the server, not on the client itself, other than having the client talk back to the server and make that validation request. So you can configure it anyway you want, but you get the best of client side response validation but securing everything on the server.

What about debugging support?

Debugging has been notoriously a painful thing with JavaScript, server side developers always kind of pooh - pooh a little bit of JavaScript, and it's this toy language, that's not for me, that's for HTML guys and we kind of have these weird conflicts. And we kind of actually need to get around that now. As we build richer and richer user interfaces we need to focus more on the JavaScript that we put in our browser. So we do a lot of testing on all of our JavaScript, we test our Java code why not we test our JavaScript code, so very, very, important.

Debugging, we have few things that we can work with within there so each browser has its little dom inspector. So of course if you do a view source in your application, what you really see is the text that was sent back to you, not the representation that is right now. So in Ajax there you could be constantly changing the page and you have no idea to know what's going on. So these dom inspectors allow you to then go through and kind of view the live page. So in some of them like Safari you literally feel just like HTML with Firefox and the Microsoft debugger you can go through and kind of click around, it's like a tree view of your page and you can also copy the HTML from it.

Some of them you have to download, Firefox has it by default. So we definitely those kind of dom inspectors that you need. There's also a very cool tool called 'modi' and that allows you to mouse over, you can just visually move around the page and it can tell you information about what's going on. So obviously it is great for development. So that's kind of that side of debugging but you want a real, real, debugger, something's going on, what happen at that point. Firefox has something called "venkman" which is the debugger you attach to Firefox, and then when you run the app, you can go through and view all of the JavaScript and you can set break points and go through them just like any other debugger.

So you can go through and debug the JavaScript side of your application and these are the kind of tools that we really need when we get to build these richer functionality, so you have to kind of get out there and look for a little bit more. It's not quite where we are in something like Java or dot net where we have this JVM that's rich, that we can go in and really see what's going on, JavaScript's VMs are kind of these black boxes, unfortunately, so we kind of have to trust the implementation and we can only test things outside of that box, but there are tools to help us.

What about IDE integration I mean is there some way to get debugging support that works all the way from the browser straight to your Java code or any other code?

Yes hopefully we'll get that on the Java side, Microsoft with Visual Studio actually has this kind of ability. You know I'm not a Microsoft guy so it kind of pains me to say this but when you're doing JavaScript development one of the best IDE's is actually Microsoft Visual Studio. It does things like, allow you to say:"I want to target these browsers with these versions" and it will tell you if you are doing something that's not going to work. It also has this round trip ability where you're going through in dev mode and it's hitting the server and doing all this stuff the way you used to even on the Java side and it can do debugging within your JavaScript.

So what are some final words about Ajax?

So I think it's a pretty exciting time, obviously it's very new, we have to totally rethink the way we are doing web applications and we have not to do that for a long time. We've seen a lot of mingling between different groups that we maybe haven't seen for a while. For example Ben and I have been speaking at a joint event with ajaxian.com and adaptive path, and adaptive path are the guys that invented the term Ajax, Jesse James Garrett and what's interesting about this event is that they draw half of the crowd that are the design people and we draw the developer people and we get everyone together to talk about different issues they need to talk about.

Traditionally we say HTML designer, design your thing, give us the mockup and we'll make it work over here in development mode. Now we've got much richer user interfaces so we need to get these developers and designers together because we need to kind of see how far we can go on these things, kind of more iterations, so the side effect is that designers and developers now have to work a lot closer. And I think that's actually a fun thing. It's a new landscape as far as usability. We're already seeing abuse, I'm sure it's going to be abused a lot these year as everyone thinks it's cool to do Ajax and they use it where it doesn't have to be.

In fact, when we do a lot of our consulting we end up taking away a lot of the Ajax stuff and going back to the simplest things because people are reinventing the wheel and the web is good in certain things and some things are good using Ajax as implementation. So it's fun to be able to get out there, try all this new usability, see all of these effects, not trying to abuse them, trying to work out how to visually kind of change our users from the standpoint that my grandma knows how to use the web because it's very, very, simple. You got links and buttons and that's pretty much it. Very, very, simple.

I look at the top right; if the thing is spinning I'm hitting a web page. With Ajax you can be hitting things in the backend all of the time. You've got no idea, and that's why we're seeing these new eye tricks being able to show the spinning graphic, showing that "oh yes, this are here must be talking back to the server". The different fade techniques that show, even though I'm up here something is fading that means something changes in that area. Now one kind of tiny little interesting thing is that amazon.com or rather apple.com changed their user interface on the shopping cart, and they changed it to an Ajax interface and then they actually went back on a bit of the Ajax functionality so to begin with, you go through, you select a very expensive Macintosh computer and every time you make a change to the component you have to click on update my stuff, it won't automatically do it.

So with Ajax obviously it's very trivial to go through and whenever you select a different component tell the server and the thing gets updated. When they first implemented that, there were all these fades and things happening in that area. Now when you go to it their next version, they don't fade in or do different things, they just mark it a particular color and they keep it a lot simpler. And we've seen a lot of that. We saw one funny example where there was this really bad error page with a really bad error, using the fade technique they put the error up and then faded it out of existence. So then a user would go through they would hit something, add something, accidentally delete an email and they won't realize they hit delete, and they went out and drink a cup of coffee, look back, there is no error message, everything is fine. So we definitely have to find the place where it makes sense these effects and the place where it doesn't and lot of cool framework coming up all of the time and keep up to day on ajaxian.com.