AJAX is great, except for the J and the X
Monday June 19th 2006, 12:00 am
Filed under: SOA/Web/Etc.

AJAX has been great for the services community. By adding asynchrony it's possible to build services that can retrieve data in the background and remain interactive with the user. This is not only great for building more powerful service interfaces but it also provides us with a critical tool in defeating latency by allowing for services to be built out of other services down on the client instead of having to mash things up on the server. I suppose life would be good then if it weren't for one tiny problem – writing code in AJAX sucks. It is, I believe, time to move beyond Javascript to a byte code environment and beyond XML to a data language that can be reasonably versioned and is truly performant.


J is for Joyless

Javascript, the J in AJAX, was designed for quick webpage hacks. It was never intended to build complex applications and building an AJAX app means building a complex application. From its lack of modularity to its lack of typing to its single threaded nature, to its dirt slow processing speed, to its lack of a decent transient local storage model to its inability to act as a true server, writing real code in Javascript really and truly does suck. I realize some of these complaints are more about the browser environment then Javascript but separating the two is nearly impossible so I'll pile them together.

There are lots of frameworks running around ranging from Javascript helper frameworks like Atlas to 'treat Javascript as a byte code' approaches like GWT but in the end they all reduce to Javascript and so just put lipstick on the single threaded, untyped, etc., pig.

I am aware of the Javascript 2.0 efforts and even if they produce an outstanding language I still don't think it's enough. One of the lessons I learned from my years in Java land is that there is not one language to rule them all. Languages are a tool and the more specialized a tool is the more productive it makes its user. So as a general rule you want languages and environments that are customized for a particular usage. This argues against one uber language and instead suggests that we want to support many different languages.

All of which leads me to conclude that what we really want is to move browsers away from Javascript and towards some kind of byte code model. But a real byte code model, one that is performant, one that supports threads, one that can provide server functionality, a local transient storage model, etc. Is this the CLR? Java Byte Codes? Anyone who read my previous blog article knows that I honestly don't care. It doesn't matter to me who wins only that one or maybe two approaches take hold so we can run with them everywhere.

The point is folks, the browser is dead, so long live the browser!

X is for eXile (I hope)

I have had the misfortune of having been involved with XML since its very early days. I remember pleading with our standards folks at Microsoft and the W3C to get XML simplified. I remember asking that we get rid of the stupid attributes, reduce the bloat and for heaven's sake put in a workable schema language. I failed on all fronts. Not one of my prouder moments I must admit.

Nonetheless XML has become a huge success, which most of us guessed would happen. That's why I pushed WebDAV to support XML. We used to joke about the XML Jedi Mind Trick. You could walk up to anyone and say "You will support XML" and voila, they would do it. Scary stuff.

XML is not beyond redemption. If the world got a clue and switched to RelaxNG then we could probably deal with XML's bloat, complicated processing model, etc. But I don't see it happening because of the huge investment in XML Schema. To me this means that XML is an evolutionary dead end. If a data language can't do versioning then it's a dead letter in the protocol world.

I have no idea what will replace XML but I must admit to some evil thoughts about JSON + XML Simple Types + a RelaxNG style schema language.

Think Again

The browser has been a success for a large number of reasons, from the simplicity of HTML (in the old days), the beauty of graphics (anyone remember Gopher?) to the power of the URL model. But I think one of the key aspects of the browser's success is that it is, in essence, a pain free application installation, execution and de-installation environment.

You can 'install' software just by navigating to it, no install dialogs to worry about, no disk space issues to check, to permissions to fret over, no conflicts to deal with, and when you are done with the "software" (a.k.a. web page) the software just vanishes (well mostly…).

All of which leads me to point out that when we look for the new browser to replace the AJAX browser we must make sure it keeps the same 'pain free' execution environment characteristics of the browser. So yes, put in server functionality, but make the server functionality disappear when the user exits the "page" (or whatever metaphor makes the most sense). By all means put in local storage, even SQL support, but make sure that the storage is first and foremost a cache. The browser can be smart about keeping cached content around for frequently visited "pages" but in the end a site has to understand that any data it puts in the cache can disappear at any time and so the information has to be backed up. And yes, we can do cool things like dynamically define where 'backed up' is so that 'backed up' could be the user's own machine or a user selected, fully encrypted, network backup facility or whatever. But that's a separate story.

Regardless of how these issues are resolved we must make sure not to throw the baby (pain free execution, URLs, etc.) out with the bathwater (modern browsers).

Go Forth and Be Creative!

I believe we have reached the end of the road for the current generation of browsers and we need something different. I'm not sure what that different thing will be but it needs to do a much better job than AJAX in terms of enabling programmers to be productive and browsers to be performant. Javascript+XML supports neither of these goals.

But one word of warning, please, for the love of G-D, do not try to standardize this next generation "thing" any time soon! As I have talked about before premature standardization is a great way to kill a market and destroy all creativity. The last thing we need is a 'designed by committee' monstrosity in an area where no one fully understands what the problem is much less the solution. Standards are what happens once innovation has come to an end. So please, allow the market to have its say!



3 Comments so far

Here, here…

This sounds vaguely familiar and we need more of such rants… The addition, a year on, is GWT and perhaps Atlas maturing. Dojo, the Yahoo browser bit, and the various framewoks are also getting better even though they too need documentation and lots of code samples.

The browser remains a fragile environment requiring much voodoo even if it is improving and we have our Venkman, Dom Inspectors and Firebugs.

The XForms and InfoPath approaches too are maturing and are players in this Great Game of Form applications. (the Infopath runtime is apparently being ported to the browser in Office 2007 – one hopes this is a cross-brower move, and conversely XForms in Mozilla is getting there slowly). These approaches aim for the declarative styles of programming.

As developers, we all want to be spoilt as we try to build rich web apps and you’ve hit the nail on the head about the need for the “pain-free execution environment”. You should be much quoted for that one.

Still it is hard to understate the importance of little things like syntax, the view source imperative and the like.

I was prognosticating that 2007 would be a fun year in this game and it is fitting. Lots more people are trying to build rich web applications and the competition is a good thing (hell those Flex folks are also in the mix). Thus the game is on.

I hope we keep the unloved html button in our sights.

Comment by Koranteng Ofosu-Amaah 06.20.06 @ 6:06 am

Though the callback function is single threaded as such, it is quite possible to make XHR multi threaded by nature.

:)

And yeah. Stupid XML bloat.

Comment by Karthik 09.23.06 @ 8:01 pm

Sorta…. my understanding is that the Javascript engines on both IE and FireFox are really and truly single threaded. However the calls out to xmlhttp can be asynchronous. This still means that you can only do one thing at a time in the Javascript although you can have multiple outstanding XMLHTTP calls. On balance this single threaded approach was a good thing because Javascript was really about ‘enhancing’ HTML, not about creating a full fledge programming language and multi-threaded programming is a pain.

Comment by Administrator 09.24.06 @ 3:49 pm



Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



nine + = 16