Thursday, October 30th, 2008

The Ajax Revolution: From UI responsiveness to functionality and beyond

Category: Ajax, Editorial

<p>This comes as part of the from my personal blog series…

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:

Productivity

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:

I also wrote about this weeks Microsoft PDC, and what it means for us all. What are your thoughts?

Related Content:

  • The revolution on the desktop
    The humble desktop PC is changing radically, in a way that promises to make the hardware more secure, enable easier PC management and provide internet...
  • The Nanotechnology Revolution
    The Nanotechnology Revolution has arrived! business intelligence and data warehousing need to prepare for the "atomic"...
  • The Nanotechnology Revolution
    The Nanotechnology Revolution has arrived! business intelligence and data warehousing need to prepare for the "atomic"...
  • Ajax Learning Guide
    Are you a Web developer? The time has come to rethink your entire approach to developing Web applications. Find out about the Ajax approach...
  • Use the soapUI software tool to tame WSDL
    You can use the soapUI software tool to tame the WSDL tiger. It is a Java-based SOAP tool offered under GNU...

Posted by Dion Almaer at 9:59 am
21 Comments

++++-
4.3 rating from 26 votes

21 Comments »

Comments feed TrackBack URI

Regarding the Workerpool and Web Workers…
.
For a long time, I’ve wished for Gears to include a good JavaScript (V8 would be nice) so that I could get decent performance in IE on computationally intensive stuff. I think this would help Gears tremendously, as I could say, “This application does some serious number crunching. Please install Google Gears for better performance. Estimated time in IE6 without Gears: 50 seconds. With Google Gears: 4 seconds.”
.
Yeah, it’s great that you get the UI out of JS’s way, but take the next step, please.

Comment by Nosredna — October 30, 2008

Well, the problem with that is that Gears is designed to be supported in as many places as possible – binding Gears / V8 as a single entity would make it much harder to implement.

Comment by fatlotus — October 30, 2008

>>Well, the problem with that is that Gears is designed to be supported in as many places as possible – binding Gears / V8 as a single entity would make it much harder to implement.
.
If I recall correctly, it was mentioned in the Google Group for Gears that a replacement for the native JS is already in one of the versions of Gears. Maybe for Opera? I don’t recall. I could be wrong.
.
I don’t see what it would be hard to implement. But of course I haven’t tried.
.
I’m just saying that’s what I really want from Gears.

Comment by Nosredna — October 30, 2008

I think increased productivity in web apps is going to depend a lot upon the ability to easily automate client side tests and get meaningful output from those automated tests in a short timeframe.

I personally have run into many problems with developers not running web tests (testing the UI with Selenium) because they just take so dang long to execute. Thus drawing a paralell between user and developer-neither likes to wait.

Jeremy Miller said that he was looking for the following out of a framework (or an application, I forget): testability, low friction and low noise. I think that getting those things to all web developers will see big gains in productivity.

I also think that the learning curve for many frameworks is way to steep. I see alot of people trying to bend this framework to do something that the other framework handles better, simply because learning the other framework is cost prohibitive. I think there are a great many usability issues in developer tools, and those issues will degrade developer performance until they are overcome.

Comment by rstackhouse — October 30, 2008

The best way to reduce the learning curve and increase the productivity is to first of all reduce the friction between the server and the client. Then to lower the boundaries for developers to entry by either doing as GWT does – compile bytecode into JS. Or as (shameless plug – I’m working with it) Ra-Ajax does – to use Managed Ajax through having a server-side API which communicates towards the client transparently.
.
Both of these solutions removes the need to teach yourself JavaScript, XHR, create server transport layers and so on…

Comment by ThomasHansen — October 30, 2008

I come from a desktop development background (Delphi and Java), and have really started believing in ajax development. It is becoming apparent that we can deliver the same power and ease of use as on the desktop, only with a dramatically better method of program distribution, data storage and data sharing.
.
However…
.
Currently I’m in the process of migrating a web 1.0 php application into the web 2.0 era. I’ve been forced to adopt a toolkit (extjs), because doing it all myself simply takes too much time. The primary bottlenecks for me have been the weakness of html form controls, the complexity of doing application layout in css / js (what I wouldn’t give for easy nestable border layouts!), and cross-browser issues (but with IE6 moving out of the picture this is becoming less of an issue). By adopting a toolkit I eliminate those issues, and my productivity becomes comparable to when I’m doing desktop development.

Comment by Joeri — October 30, 2008

Over in java land they’ve coined the term SOUI (Service Oriented UI) and SOFEA (Service Oriented Front End Architecture) .. I’d like to see one of the major toolkits extend along these lines.
.
AJAX gives us a degree of SOUI .. we can make services calls whenever we want, but SOUI goes a step further, it moves the whole server based MVC paradigm into the browser. Whilst there are a few attempts to do this (eg javascriptmvc.com), my opinion is they are overkill. We need dojo or ext.js to come up with a lightweight iframe navigator that housed within a controlling page, navigates between the frames as any MVC serverside framework will do. Now that has implications on bookmarking internal pages and so forth, but as web apps become more app-like, bookmarking is reduced to holding the launch page.
.
Talking about productivity .. remove the reliance on a server side architecture so you can develop your app statically .. watch productivity improve.

Comment by simongil — October 30, 2008

@simongil
You’re right, though removing the reliance on a server-side architecture doesn’t come anywhere near the productivity increase as removing the need to do JavaScript and client-side programming…
.
First of all security is *implicit* with a Managed Ajax Framework (unless you intentionally break it), second of all you’ve got only one architecture to think about since the framework abstracts away all the differences between the browsers. Third of all you get one programming language to think about instead of (at least) two which you need to think about unless you’re only developing on the client-side. Which obviously is ridiculous. Fourth of all you get way less hacks to get different browsers to work (most of the time *no* hacks at all in fact). Fifth you get way more responsive applications since you often end up with way less JavaScript….
.
List basically goes on into infinity…
.
Here I’m creating a CRM system in less than 20 minutes while at the same time I’m explaining everything I do.
http://ra-ajax.org/ra-ajax-video-tutorial-creating-an-ajax-crm-system-in-20-minutes.blog
* One programming language (you can choose language in fact too between about 50 different ones)
* Runs on *every single browser* I’ve tested it on which is like about 50 different ones ranging from Opera the Kubunt Version to Safari the iPhone version. No need to do anything to get it to run either.
* Scores 86 in ySlow *out of the box* BEFORE we start gZipping the JavaScript, CSS and HTML.
* You get to leverage all the best practices and tools if you want to like Castle MonoRails, ActiveRecord, nHibernate, log4net, you-name-it…
* Security is bullet proof since you’re in “server land” unless you intentionally break it…
etc, etc, etc…
.
Either I must be the dumbest redneck in history and my observations are pure hallucinations, or me [and some few other people] have seen the emperor naked and are desperately trying to convince others about that fact to help move the world forward – You be the judge…

Comment by ThomasHansen — October 30, 2008

@ThomasHansen,
.
Looks like you have a great system.
.
I think the idea of one language for both server and client makes a lot of sense.
.
Of course, for me that means looking for a good JavaScript server.

Comment by Nosredna — October 31, 2008

@Nosredna :-)
.
@Thomas
All power to you and hope it goes well! But with respect, I just don’t buy it. Put simply, the *browser-is-the-platform*. Learn to develop for it natively (html/css/javascript) and reap the benefits. With browsers able to support more and more sophisticated UIs, and as the javascript platforms themselves evolve, we are getting treeviews/listgrids/tab folders/sliders/accordians and all manner of custom layout, all functioning in the one UI with plenty of interdependence between widgets (and then throw in variations of ro/rw behaviour). Trying to program UI logic from the server just handicaps these sorts of developments (I’ve just finished a gwt-ext.js project and after doing things directly in JavaScript to have to do everything via a java-widget api just dropped productivity enormously).
.
If you want to do everything from the server .. go for it! But I won’t follow you. I want native access to the platform I’m deploying to.

Comment by simongil — October 31, 2008

@nosrda
Thanx :)
Obviously there’s also the point of just programming in *one-platform* too which you don’t get by having a JS server in addition to a JS client-side API. Not to mention the fact that when you develop for both the browser and the server you do twice the work compared to what you do when only developing in one of those places. This creates all sorts of problems like for instance what happens when you update one of them but forget (or do it buggy) when updating the other place…
.
@simongil
Great words, and I agree completely with them, though CISCx86 is also the “platform” when developing for KDE, Gnome or Windows. Does that mean we should develop in assembly, or does it mean we should try to find good abstractions which increases productivity…?
E.g. WinForms, Qt, wxWidgets etc…
.
PS!
About your experience from ExtGWT…
Thomas Edison spent 2000 attempts getting the light-bulb right, just because he had 1999 failures doesn’t mean the idea was flawed. I know nothing about ExtGWT other than that I’ve heard it builds on top of GWT – Which I think is a *great* idea (compiling bytecode to JS to abstract away JS (which is the underlaying *idea* here)). But to judge an idea because of *one* implementation is not being fair to the idea… ;)
.
When that is said I am confident in that Jack Slocum and the others in Ext LLC will figure this out someday. If they have figured it out already I don’t feel knowledged enough about ExtGWT to say anything about… The *idea* though is *brilliant*…!!!
.
The first stottering programming languages which tried to abstract away ASM was also pretty crappy, that doesn’t mean COBOL didn’t increase productivity in addition to all the other benefits it brought…
.
Might be that Ra-Ajax and similar types of frameworks like GWT and ExtGWT is “nothing but the COBOLs of today”, but I know that at least in the case of Ra-Ajax productivity *explodes* compared to “ASM coding”… ;)
Just like COBOL did 50 years ago…
.
PS!
Managed Ajax defined; http://ra-ajax.org/managed-ajax-a-new-approach-to-ajax.blog
The above blog speaks about both the advantages *and* the disadvantages when using Managed Ajax Frameworks. I am more than willing to admit that un-managed Ajax frameworks have advantages…

Comment by ThomasHansen — October 31, 2008

@ThomasHansen: Your x86 analogy doesn’t quite measure up. The productivity increase moving away from direct assembly comes from reducing the number of lines of code you have to write, thereby reducing development time and defect rate. Does your platform let me write less lines of code than when using a javascript toolkit and coding a mixture of server and client code? Somehow I don’t think the difference is that big.

Comment by Joeri — October 31, 2008

@Joeri
Create a new Ajax Modal Window with some HTML text and a button with an event handler is like this (angle brackets changed to [])
[ra:Window runat="server" id="wnd" CssClass="alphacube"]
[div style="padding:15px;"]
[h1]Howdy dudes…[/h1]
[ra:Button runat="server" id="btn" OnClick="foo" Text="Click" /]
[/div]
[ra:BehaviorObscurable runat="server" id="obscurer" /]
[/ra:Window]
.
C# codebehind file;
protected void foo(object sender, EventArgs e)
{
new EffectHighlight(btn, 200).Render();
}
.
This will create a modal Ajax Window and have a button with a C# event handler which will animate the button. Notice also that here we are *on-the-server* in the “foo” method meaning we’re able to directly access database (without security risks) and logging on the server etc. Not to mention there’s no “gluing code” to make that call back to the server. All of that stuff is implicitly given to you :)
.
I’ve seen similar things in JS though most of them require orders of magnitudes the amount of code in comparison…
.
Beside the real advantage comes when attaching *logic* to the thing since then you can take advantage of already being on the server and directly use stuff like ActiveRecord, nHibernate and all that stuff etc…
.
To create client-side “bling” is almost as fast in a JS library as in a Managed Ajax Framework, but when you start attaching *logic* to it like reading customers from a database, inserting new records into your contacts table and such – then the real difference kicks in ;)
.
Not to mention the far more clean code model…
.
I am not sure, but I think this is a general pattern with all Managed Ajax Frameworks…

Comment by ThomasHansen — October 31, 2008

I have nothing against the way anyone wants to program, and am always willing to try another.
.
I also find OpenLaszlo interesting. I think that’s a great idea. But for now I feel “safer” in Dojo and jQuery because I KNOW that thousands of others are using it, and if I get stuck, I can Google for a solution.
.
Objective-J gives me qualms, too. I can’t afford to commit (professionally) to a rare dev choice. Now, on a hobby level, awesome. Amiga E, Atari 800 Action!, Forth, APL. I have and will try anything.

Comment by Nosredna — October 31, 2008

Anyway, getting back on the topic of the article again, I do worry about the direction of the ajax community. A lot of effort goes into stuff like comet, canvas, alternative input (multi-touch), and so on. These are all nice, but honestly, they are not what business apps are about, and the majority of apps are still business apps. I would like to see that sort of effort go into improving forms. Why is there no standard validation mechanism? Why is it such a pain to layout forms? The bias in the development direction is heavily on the “toy” side of things, not on the business side.

Comment by Joeri — October 31, 2008

@Thomas:
.
“I’ve seen similar things in JS though most of them require orders of magnitudes the amount of code in comparison…”
.
You’re claim is skewed. Pure JS solutions are cached after initial load (of less than 10k if the implementer isn’t an idiot) for the entire site. With a server based solution you have a viewstate which is not cached. So instead of a one shot 10k for the whole website, you get nickel and dimed for 2k or more on every page you use the effect.
.
@Joeri:
.
Look at the html 5 forms and XForms, they include what you are talking about. As for laying out forms, its not hard if you keep in practice with your CSS. (Think outside the Box…er… Table)
.
@simongil
.
100% agree with you there.

Comment by TNO — October 31, 2008

ThomasHansen
Watched some of your video, you claim to be able to build a CRM system in 20 minutes, but you paste all your code in.
And with all the littel “And now I just have to remember…”-comments in your video I really don’t think anyone but yourself could do what you do in 20 minutes…

Comment by ebdrup — October 31, 2008

@ebdrup
Well, I am cheating a little bit during the video to get it into 20 minutes, but I am also explaining thoroughly what I am doing and also what that pasted code is doing which I think probably will go up in up – as in if I didn’t have to walk through and explain everything I did and everything that was in that pasted code I think I wouldn’t spend more than 20 minutes actually creating it. But it is a video tutorial and it’s purpose is to teach, not to proof anything.
Also Ra-Ajax is purely built on top of the existing WebControl paradigm in ASP.NET which means if you know WebControls (which 7.5 million on the planet knows) you know Ra-Ajax so I don’t think that last statement is true either.
But yes 20 minutes would hold hard for everyone trying to repeat that (including me) code. But the places I (and others) would get stuck would often not be in the UI parts but the Customer.cs file where we would have to experiment a little bit and such before “getting it home”.
.
@tno
Of course you’re right here, still even the landing pages of every large JS framework vendor scores less in YSlow than that video tutorial gets directly out of the box for free. As you can see here;
http://ra-ajax.org/comparing-popular-ajax-frameworks-in-yslow.blog
Most of the JS frameworks are getting scores in the 50s and 60s – while Ra gets 81 – and this was before we implemented GZip releases.
So now it would get like 95 (gzipped version) out of the box.
Also ViewState can be turned OFF in Ra-Ajax, in addition you can implement solutions which keeps it on the server, all though the last thing *is* difficult I agree…

Comment by ThomasHansen — November 1, 2008

@joeri: Hey Joeri; I like how you mentioned about focusing on the business side as well as other aspects of the web. Are you open to talking about ways we can evolve the web to better handle business cases, such as forms validation and better layout? Contact me at bradneuberg ATATATAT google.com.

Best,
Brad Neuberg
http://codinginparadise.org

Comment by Brad Neuberg — November 2, 2008

I think AJAX developers also need to worry about bringing the ajax experience up to par eith desktop applications. For example we need to put undo/redo functionality in our applications.
I’ve written an article about that at http://obsurvey.com/Articles/Wheredidundogo.aspx

And I think we need more stuff like that, we need well structured frameworks that provide good abstractions, where you can spend more time worrying about your model and not so much time in the view of tings.

Comment by ebdrup — November 2, 2008

I completely agree with ebdrup with regards to the undo/redo functionality. Sometimes we have to work hard and not getting left behind.

Comment by rdajaxgrl — November 5, 2008

Leave a comment

You must be logged in to post a comment.