Pulling Back from Extreme AJAX

I always thought that Jesse-James Garret had an awesome name. It is up there with Megan Foxx and that episode of The Simpsons when Homer briefly changed his name to Max Power. How many of us have a name that prompted John Lee Hooker to compare his level of badness to us? Granted, the Jesse in question (Jesse Woodson James) was too busy robbing banks and leading gangs to be a Chief Creative Officer of anything, but the power of the name is undeniable.

JJG, of course, is the guy who coined the phrase ‘Asynchronous JavaScript and XML’ (AJAX). It put a name on the technique that turned JavaScript from a quirky scripting language for coding web site menus to a powerhouse, delivering amazingly interactive Web applications to your browser. If we wanted to be sticklers, the majority of people now use JSON, not the original XML for the X part of the technique, but would we like JJG as much if he called the technique AJAJ? I don’t think so.

AJAX works roughly like this: in the dark ages of Web 1.0, whenever you wanted to react to user input in a significant way, you had to pass the data to the server and get a new rendition of the page. A lot of effort went into hiding this fact – session state was kept, parameters were passed, resources were cached to speed up page redraw, but it was still flashy and awkward – nothing like the creamy smoothness of desktop application UX. Then Microsoft needed some hooks, first in Outlook, then in IE, to make asynchronous requests to the server without the need to reload the page. The feature remained relatively obscure until Google made a splash with Gmail and Google Maps in a way that was browser-agnostic. Then JJG called the whole thing AJAX. You can read it all on Wikipedia.

Fascination with AJAX was long lasting. I guess we were so used to the limitations of Web 1.0 and what browsers were supposed and not supposed to do that for the longest time we had to pinch ourselves when looking at so much interactivity without page reload. I remember watching Google Wave demo at Google IO conference in 2009 and the presenter kept saying “and remember, there are no plug-ins here, this is all done with JavaScript in a regular browser”. Four years after the phrase was born!

There is a self-deprecating American joke that claims that “it is not done until it is overdone”. I live in Canada but when it comes to AJAX we are equally culpable. In our implementation of AJAX in the Rational Jazz Project, we served AJAX for every meal. We had AJAX hors d’oeuvres followed by AJAX soup, AJAX BBQ and then triple-fudge AJAX for desert. No wonder we now suffer from AJAX heartburn. Will somebody pass the Zantac?

See, the problem is that it is easy to overdo AJAX by forgetting that we are not writing desktop applications. We still need to have the healthy respect for the Web and remember that it is a fundamentally different environment than your desktop. Forgetting this fundamental tenet usually leads to a three-stage illness:

1. Obesity. As in real-world diet, AJAX calories add up, and before you know it, your web page is ready for the Fat Farm. I have seen a page that needed to load more than 1MB of JavaScript (gzipped) before anything useful was shown.
2. Separation Anxiety. Since it takes so much effort to load a page and make it useful, fat AJAX apps fear browser separation and do everything in their power to avoid a refresh. It can degenerate all the way to ‘one page apps’ that stay around like a bad penny, all the while faking ‘pages’ with DIVs that are hidden and shown via CSS.
3. The God Complex. The final stage of this malady is that since we are not leaving the browser, and since any nontrivial app needs to manage a number of objects and resources, we come up with elaborate schemes for switching between them, lying to the browser about our navigation history, and finally fully re-implementing a good number of features that browsers already do, only much better. Pop-up menus, history management, tab management – we essentially ask the browser to load our app (painfully) and then go take a nap for a couple of hours – we will take over.

Should we lay this at the doorstep of Microsoft, Google and JJG? It would be easy but it would not help us. Nobody asked us to lose control of ourselves and amass such JavaScript love handles and triple chins. No AJAX Hello World snippet has 1MB of JavaScript. AJAX is wonderful when used in moderation. Large, slow to load AJAX pages are a problem even on the desktop, and are a complete non-starters in the increasingly important mobile world. Even if you ignore the problem of moving huge JavaScript payload over mobile networks, JavaScript engines in smartphone browsers have much smaller room to play and can cripple or downright terminate your app. By the way, this kind of defeats the purpose of so called ‘hybrid apps’ where you install a web app as native using PhoneGap/Cordova shim. That only eliminates the transport part but all the issues with running JavaScript on the phone remain. I am not saying that hybrid apps don’t have their place, only that they are not exempt from JavaScript weight watching.

How does a page wake up one morning and realize nothing in the wardrobe closet fits any more? Writing 1MB worth of JavaScript takes a lot of effort – it does not happen overnight. One of the reasons are desktop and server side developers writing client code but still somehow wanting to think they are in their comfort zone. A lot of Java developers think JavaScript is Java’s silly little brother. They devise reality-distortion force fields that allow them to pretend they are still writing in strongly typed languages (I am looking at you, GWT). Entire Java libraries are converted to JavaScript without a lot of scrutiny. I am strongly against it. As I always say, si fueris Romanae, Romano vivito more. If your code will end up running in a browser as JavaScript, why don’t you write in JavaScript and take advantage of all unique language features, instead of losing things in translation and generating suboptimal code?

But it is not (just) suboptimal code generation that causes the code bloat. It is the whole mindset. Proper strongly typed OO languages encourage creating elaborate class hierarchies and overbuilding your code by using every pattern from the Gang Of Four book at least once. That way the porky code lies. Coding for the web requires acute awareness that every line of code counts and rewards brevity and leanness. As it turns out, you pay for each additional line of JavaScript three times:

1. More code takes longer to send to the browser over the moody and unpredictable networks
2. More code takes longer for the browser to parse it before being able to use it
3. More code will take more time to run in the browser (I know that JavaScript VMs have gotten better lately, but in the real life I still need to perform an occasional act of scriptocide – JavaScript performance problem didn’t entirely go away)

And what would an article by a middle-aged architect be without an obligatory “kids these days” lament? Many of the newly minted developers start out on the client side. They become very good at coaxing the browser into doing wonderful things, and this affinity naturally degenerates into doing ALL your work on the client. The server essentially becomes a resource delivery layer, sending JSON to JavaScript frameworks that are doing all of the interesting work in-browser. This is wrong. The proper way of looking at your application is that it consists of the following parts:

1. Storage (Model)
2. Server side logic (Controller)
3. Server side rendering engine (View)
4. Network transport layer
5. Browser that renders HTML using CSS and reacting to user interactions via JavaScript

Notice how JavaScript is one of 7 aspects you need to care about. If you look at some implementations these days, you would think all the other aspects only exist to deliver or otherwise support JavaScript. It is the equivalent of a body builder that focused all his training on his right arm biceps. A balanced approach would yield much better results.

OK, Dejan, quit pontificating. What do we do to avoid dangers of irresponsible AJAXing in the future?

Well, armed with all this hard won experience, we have decided to take the opportunity of the new Jazz Platform project to wipe the slate clean and do things right. We are not alone in this – there is evidence that the pendulum has swung back from Extreme AJAX towards a healthier diet where all the Web App food groups are represented. For example, a lot of people read a blog post about Twitter performance-driven redesign, driven by exactly the same concerns I listed above. More recently, I stumbled upon an article by Mathias Schäfer arguing for a similarly mature and sane approach that embraces both the tried and true Web architectures and the interactivity that only JavaScript can provide.

You will get much better results by using the proper tool for the job. Want to access stored data fast? Pay attention to which storage solution to pick, and how to structure your data to take advantage of the particular properties of your choice. Need to show some HTML? Just serve a static document. Need to serve a dynamic document that will not change for the session? Use server side MVC to render it (I am talking a concept here, not frameworks – many server-side frameworks suffer from similar bloat but it is less detrimental on the server). Use the power of HTML and CSS to do as much rendering, animation, transition effects as you can (you will be surprised what is possible today with HTML5 and CSS3 alone). Then, and only then, use JavaScript to render widgets and deliver interactivity that wowed us so much in the recent past. But even then, don’t load JavaScript widgets cold – take advantage of the server-side MVC to prime them with markup and data so that no trip back to the server is necessary to render the initial page. You can use asynchronous requests later to incrementally update parts of the page as users go about using it (instead of aborting it half way because “this thing takes forever to load, I don’t have that kind of time”.

Eight years since AJAX has entered our vocabulary, the technique has matured and the early excesses are being gradually weeded out. We now know where overindulgence in JavaScript can lead us and must be constantly vigilant as we are writing new web applications for an increasingly diverse browser and mobile clients. We understand that AJAX is a tool in our toolbox, and as long as we don’t view it as a hammer and all our problems as nails, we will be OK. We can be bad like Jesse-James, guilt-free.

© Dejan Glozic, 2013