A new experiment cleaning up house as I move to a new Mac Microsoft say Game On; Thoughts on PDC
Oct 28

The Ajax Revolution: From UI responsiveness to functionality and beyond

Ajax, Tech Add comments

In recent presentations, Ben and I have been taking a look back on the rise of Ajax (where Ajax == popularity of dhtml :). At its core, I think it all comes down to UI responsiveness.

When you look at the killer apps such as Google Suggest and Maps, they broke through a set of myths on the Web.

Latency is the killer issue on the Web

We are used to autocomplete in fields and forms these days. However, if you think back to when Google Suggest came out, if someone had asked you whether it was a good idea to do a background request on each key press you may think they were insane. The beauty of suggest is that it broke through and gave great performance. You could do this on the Web.

Rich interactions are not possible on the Web

Again, we are used to applications that allow us to interact with data in a better way. With Google Maps, you feel like you are moving around the map. You are interacting closely with the data. Before hand, we were used to a static view that had us clicking up/down/left/right or zooming around. Every click responds with a wait and a repaint of the entire screen.

This seems crazy. No application framework would ever do a refresh like this, and dhtml broke us out of that box.

This is all pretty obvious, especially when you take a look back at the HCI research on how anything that takes more than a second drives your users batty (and gets them out of the zone). Getting down to 0.1 seconds and your users will feel like they are at one with the app :)

The responsiveness that Ajax gave us opened up the Web for truly useful applications that users could live in without getting frustrated. This bridged us from pages to apps.

We continue to see movement here too. The reason that WorkerPool was added to Gears (Web Workers in the standard) was to give developers the ability to send “work” (run code) to a place that isn’t on the UI thread, which is a big no-no for building any kind of responsive application. As we write bigger and bigger Ajax applications, we end up running more code, which competes more with the browser. Having Web Workers in the browsers natively, and available to those that don’t via Gears, allows us to build compelling applications.

Add to this fast JavaScript (SquirrelFish Extreme, TraceMonkey, V8), and we can get to a happy place with respect to performance.

So, if the original Ajax revolution was about UI responsiveness, where do we go from here?

I think that we have a few directions that we need to go in:


We need to be more productive. We all feel a lot of pain with Web development, even as we get a lot of benefit from the reach and openness. This is pain is the reason that Ben and I are working under a developer tools umbrella at Mozilla. We want to work with the community to become more productive. It is extremely important to do so.

It shouldn’t be hard to put together the hundreds of applications that the Enterprise and beyond spend too much time and money on every day.

We shouldn’t have to fight the browsers to get things working as much as we do today.

Any ideas on what would help you? We are all ears.

Compelling applications

We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences.

Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications.

The browser is extending to the desktop more, to give you nice full experiences. The real-time Web is kicking off, and Comet will become a big part of how we develop many applications in the future. It needs to be as natural to us as the simple request/response world that we are used too.

UI latency is only one piece of user experience. There are many others. HTML 5 gives us richer components and semantics to work with. We have been working on different UI paradigms such as the Form History pattern that we have discussed before. Aza Raskin and others have been doing really good work on new paradigms too.

Personally, I think that new input devices are going to create a huge change for us, and the abilities of Web applications. We played with the WiiMote as an input device. We then have multi-touch, which is available on touch pad devices as well as touch screens. Finally! We are moving past the prehistoric inputs where we can point and say “Ug”.

I am incredibly excited about where we are, and where we are going. There is a ton of work to do, but people feel engaged. Let’s “get ‘er done”.

Where do you think we are going?

This presentation goes over some of these points, in more detail:

4 Responses to “The Ajax Revolution: From UI responsiveness to functionality and beyond”

  1. Brian LeRoux Says:

    Just as design patterns are symptoms of language deficiency I believe frameworks are symptoms of deficient platforms. The various browser vendors need to step up their game make these frameworks irrelevant and work together to improve the language on obvious fronts: querySelectorAll for example. That said, its never gonna happen, but there does seem to be some level agreement to disagreement. People are gonna choose their js frameworks and thats it.

    Tooling such as Firebug, Inspector (droseria) and whatever IE developers use are a good start but could be vastly improved with better code generation, test framework output integration (specs?)…. Watir/Selenium style testing built right into the browser for automation and testing.

    The language itself could have more utility. What about an IRB like console for JavaScript for scripting with full file system access? I suppose Rhino could be a way to do this / should check that out myself!

    Thanks for this Dion — look forward to seeing what you guys cook up!

  2. Brad Neuberg Says:

    Hi Dion, we are in exactly the same place (of course :) As I’ve been out here doing the GDDs I’ve been taking some time trying to think about where we are headed on the web in general. It’s like we are fighting these battles to just eke out small improvements; we need more. I mean, things like HTML 5, the Canvas tag, and more are great, but are they enough? Things are still too hard to create, the functionality we need needs to be more compelling, and more. We should definitely meet up when you are back from your sabbatical and I’m back in the states :)

  3. SchizoDuckie Says:

    I think there could be a couple of things the mozilla foundation could do:

    * Create a ‘mozdev/sourceforge’-alike site for plugins for all the favorite js libraries out there, with good info for the developers and standard demos to get started
    * Host the all versions of the js libraries like the google project, but then keep up with the releases
    * Maybe even try to create a standard for deploying javascript libraries into the browsers themselves. It would save all users loads of time if they don’t have to keep loading the same libraries. Just identify jquery, mootools, whatever and save them in a special ‘cache’ that maybe even precompiles them for the new JS engine
    * *Keep Updating FIREBUG!*

  4. dion Says:

    @Brian, Some good ideas, I will noodle on them. Firebug can do some of that, and it can do more. Firebug is starting to cook again.

    @Brad, Yeah ma man. Let’s do it :)

    @Duckie, Great ideas. Keep them coming. We are listening!

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What are the first four letters in the word British?