Is AJAX a hack?

In The Clingan Zone: Is AJAX a hack?  John is making good points about how a web browser can/should be used.

But for me the key focus for web technologies and therefore for this debate is the separation between user client and server.

When servers deliver over http then Web Browsers are only one potential client and the server should not need to care about the client. A danger with AJAX is that we tightly couple the server implementation to a specific client. The same danger is possible with all the alternatives to Web Browsers, using Java may help with cross platform issues, but loose coupling and REST based interfaces help even more with cross client issues.

I believe that AJAX should/must not break all that we have learned in the move towards REST as an architecture for web applications. I am therefore not in favour of using AJAX where the server returns javascript data structures or anything else but XML (or maybe as we are not all ready for that HTML as an interim measure). This way other clients can use the same server interface as our rich AJAX applications running in web browsers.

Of course it also helps that simple REST interfaces to the server are easier to debug, test and automate than anything else.

This was one of my reasons for working with Leonardo as a platform for the websites I am working with.

Comments

[Paul Boddie]

I remember reading recently someone's blog where they said that applications returning HTML in response to "AJAX" requests (how I hate to use the term) somehow missed the point of this particular bandwagon.

It's nice to see how, in the struggle to make the server application some kind of generic, user-interface-agnostic container, code ends up being written twice because some browsers won't support fancy JavaScript tricks and thus need their layout given to them in HTML, while the capable and willing browsers do their "incremental rendering" using JavaScript code, spitting HTML directly into the page. And all browsers have to receive the initial pages in HTML anyway, unless you're doing some kind of nasty JavaScript bootstrapping of the user interface (which I have seen on various occasions).

"Don't repeat yourself!" chant the faithful, over and over again...

[DaveW]

Paul,

I think it takes time (and probably several generations of application development and deployment) to realise some of the implications of "Don't repeat yourself". In my experience it is a rule that commercial development tools do least well, they want you do everything within their environment which clearly means re-doing anything that was working well and existing before.

Fortunately the basic specs and the free software community at least permit you do follow this principal more closely.

On the other hand doing something for the 3rd time can be a good learning mechanism (particularly for those of us who are a bit slow on the uptake), certainly I don't want to admit to how many times I have learnt that way ;-)

Dave

Dave

[Marko Samastur]

Just a short comment. I think main reason why so many of us use javascript data structures instead of XML is plain speed.

It might not matter if XML (or data structure) is fairly small, but you can clearly see the difference on bigger sets even on a fairly new computer. If speed doesn't matter, then why bother with AJAX at all. Just do the round trip to server.

I think it's nice to use XML when you can or even not use AJAX at all, if the benefit of it is small. I hardly think JS structures are a problem though, since JSON clearly shows how easy it is to use them in practically any language you care to think of.

[Paul Boddie]

Dave, you're certainly right about it taking several iterations before one realises how things should be done. I was just pointing out the dilemmas faced by adherents of various programming ideologies.

Marko, in my experience, you don't want large XML documents in your Web browser unless you've got a very powerful computer, regardless of how those documents get constructed (either by interpreting other kinds of data and creating/replicating nodes in JavaScript, or by just pasting/importing XML/HTML fragments into a page). Web browsers have to do a lot with their XML documents, and all the machinery will inflate the memory and computational requirements significantly compared to a "normal" XML toolkit. For me, that's an argument for doing heavier presentation work on the server.

[DaveW]

Marko,

To my thinking the issues about speed with AJAX mostly relate to latency not bandwidth nor client processing speed.

JSON might be interesting, but IMHO it is focusing on premature optimisation. There are now many alternatives that are supposed to be better than XML, but they lack standards and the support is limited. Among the advantages of XML (besides the browsers being able to display it directly) are schema support eg RelaxNG. These make it simple to validate servers from a wide variety of client tools.

Also I am very wary of using eval() on anything that I have as little control over as data coming over public networks. Look at the recent security hole in the PHP libraries for XML-RPC as an example.

So you are suggesting that we replace an established standard (XML) with support in browsers and just about every programming language, with validating parsers, with schemas etc in order to gain a little processing speed on current web browser clients. Seems rather a short term solution to me.

I also think it is good that XML is more clearly separated from the programming languages. It encourages you to think in terms of documents, not procedure calls and that is the REST way. That is important when designing a server API if it is to have long term value.

So no, I don't personally think JSON is a good way to go for AJAX.

[Marko Samastur]

No, I'm not suggesting to replace XML with anything. It certainly has its place, although I do think it's sometimes overused.

I think points about latency, eval and rest are valid and something every developer should take into account. However, what prevails really depends on situation.

Not everyone uses broadband and not every application is written for such an environment and as experienced not long ago, a lot of them (and I don't mean just AJAX applications) break horribly when faced with high latency and low bandwidth environment.

I also think it's a fact that most AJAX applications right now have very limited goals. They just want to work with their own server and everything that doesn't make that easier is just getting in a way. Of course, if that is good or bad depends on your point of view. Personally, I don't think there's a view, which is right for all occassions.

And it might help to imagine that what some of us do over the web has nothing to do with documents (even conceptually) so thinking in such terms is not always helpful.