Is AJAX dead?

I'm going out on a limb by predicting the death of our friend AJAX. She was a good workhorse, but she needs to be put out to pasture. Experienced developers can tell stories about how we were using AJAX before it was named as such. It accidentally became the standard for communicating with the server and updating the html on the client side without a page refresh.

It's a hack, a terrible name (no one uses the X in AJAX, xml, everyone uses JSON, but AJAJ doesn't roll off the tongue as nice), and it's not the right way to do it.

Let's think about the current state of thick-client web development for a minute:

) We use a scripting layer and framework such as Python/Django, PHP/Symphony, or Ruby on Rails to generate HTML to deliver to the client over HTTP. These don't natively speak HTTP, so we have a separate server to handle that.

) We use javascript to listen to events from the user, then construct a request to send to the server over HTTP.

) The server then interprets/deserializes that JSON with the scripting layer, does it's work, then produces a JSON response back to send back to the client, over HTTP.

) Each one of these requests, while they are asynchronous, require a separate transaction, so pushing updates to other user isn't usually done. HTTP long polling is a hacky workaround to avoid the http handshake, but it's suboptimal.

) The client then receives the JSON back, deserializes it, and it must rebuild the HTML using a different templating approach on the client.

This is what front end engineers do all day long. That's just silly. It's an awful lot of serialization/deserialization across different languages. The extra work, CPU (constantly re-establishing HTTP and serializing/deserializing), and number of moving parts is too high.

I think the new approach that will disrupt this paradigm is to use server side javascript (node.js), websockets* as the communication layer, and native javascript/JSON the whole way.

Advantages:

* One language.

* Stop serializing/unserializing javascript/JSON on both sides

* Same templating on both server and client. No more Django/PHP/Rails on one side and then Mustasche/Icanhaz/EJS on the client. Write templates once, and build HTML the same way.

* One language for developers to learn/master. One expertise to hire for.

* Lower overall CPU usage.

* Less moving parts (node instead of Apache + Scripting Layer)

* Less data munging

* Templating on the *client* side

* Async/Event driven approach scales better

* Websockets are a stateful connection, so updates can easily be pushed to users when updates happen.

* Javascript's event driven model makes more sense for highly interactive web pages; theoretically easier to scale. Note: Has anyone seen node.js in a high scale production environment?

This framework Meteor is on the right track, they use a combination of web sockets (unconfirmed), native js execution, backbone.js for managing the models. Check out the screencast to see it in action., and to see what's possible when this paradigm is implemented. http://www.meteor.com/

What's in the way of this happening?

* Node.js is still immature, and Operationally it's not production quality

* The frameworks for node.js are still immature. Connect / Express are the current leaders. The community is fragmented and seems to have attracted a lot of the Rails community.

* Event driven programming is hard. My brain doesn't think that way intuitively.

* Browser support. Not all browsers support web sockets. Comet is the best way to gracefully degredate for those that don't. Socket I/O also eases the pain.

* A retraining of stodgy old web developers like us :)

Other opinions and insights appreciated.

-Nick

Reading:

http://en.wikipedia.org/wiki/WebSocket

http://en.wikipedia.org/wiki/Comet_(programming)

http://nodejs.org/ # the best server side javascript platform

http://www.senchalabs.org/connect/ # popular http framework for node.js

http://embeddedjs.com/ # a javascript templating layer that works both client and server