AJAX is great, except for the J and the X

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!