Server-Centric versus Browser-Centric

So is the web application of the future going to be static HTML & JavaScript, served up by Apache with Ajax interacting with a bunch of XML based web services (maybe using SOAP, maybe just REST etc)? If so, do we really need a web framework thats focussed on HTTP and HTML, or are we just gonna end up developing a bunch of XML based web services and letting Ajax do all the templating, editing and viewing?

While I’ve kept [an open mind](http://ajaxpatterns.org/Ajax_Frameworks an open mind), pure separation is certainly the approach I’ve been using and advocating. Perhaps server-centric approaches can work okay for some intranet apps where the emphasis is on getting up and running, and where many developers want to focus on server-side concepts like messaging, DB, business logic, etc. But the bulk of applications are better off as browser-centric.

With tools like Dojo, Mochikit, Scriptaculous, Ajax Pages, you can quite happily get the whole UI encapsulated in JS. Amid all the Ruby uptake (and for good reason), JS has also come along nicely over the past twelve months. Not just libraries, but techniques for OO design, testing, etc.

In addition, as others have pointed out, the approach goes hand-in-hand with SOA: if you’re going to expose a clean REST API on your server anyway, it’s a no-brainer to proceed with a pure-browser UI. Testing becomes a lot easier too. Separating model and presentation has always been a difficult problem in software … when you have a solution as good as this, you have to put up a very strong argument against it.

So why are people still using server-centric frameworks? The biggest force of resistance seems to be the misplaced notion that JS is a hack and we must avoid working with it at all costs. Or maybe it’s less ideological than that, and because people just haven’t had time to learn it. Fair enough – it’s hard enough to keep up with server-side technologies. But a little time learning the basics of JS would certainly ease the pain of web development.

4 thoughts on Server-Centric versus Browser-Centric

Well spoken. However….
a) I don’t see inherit a conflict between server frameworks and ajax/rest based approaches. At the end the server must validate if bits and pieces fit together and there you at least need to orchestrate your services.

b) I haven’t come across a decent JS IDE — but you might enlighten me — with robust support for Intellisense even for our own objects.

c) I don’t see it feasible from a security point of view to expose too much business logic in the browser’s JS. So still some heavy lifting needs to be done on the app server.
…
Anyhow – we are living in interesting times!

Well spoken. However….
a) I don’t see inherit a conflict between server frameworks and ajax/rest based approaches. At the end the server must validate if bits and pieces fit together and there you at least need to orchestrate your services.

b) I haven’t come across a decent JS IDE — but you might enlighten me — with robust support for Intellisense even for our own objects.

c) I don’t see it feasible from a security point of view to expose too much business logic in the browser’s JS. So still some heavy lifting needs to be done on the app server.
…
Anyhow – we are living in interesting times!

The one thing that will kill Ajax (Its already dead in the water as far as I’m concerned, along with nearly all other client side javascript augmentation) is accessibility requirements. Goverments and corporations are under increasing pressure (legal / fear of being sued) to make their content accessible to screen readers. Javascript ties screen readers up in knots. And thats a fact. Most small to medium businesses cant afford the testing time needed to test a site properly with a screen reader. And the price of screen readers are exorbitant too. The development / learning time involved in Ajax is high. This will make most developers (and I mean real developers with real deadlines that dont have time to deliver two solutions like gmail) steer clear. Anyway, Ajax is great for all us sighted developers with tonnes of time and cash.

The one thing that will kill Ajax (Its already dead in the water as far as I’m concerned, along with nearly all other client side javascript augmentation) is accessibility requirements. Goverments and corporations are under increasing pressure (legal / fear of being sued) to make their content accessible to screen readers. Javascript ties screen readers up in knots. And thats a fact. Most small to medium businesses cant afford the testing time needed to test a site properly with a screen reader. And the price of screen readers are exorbitant too. The development / learning time involved in Ajax is high. This will make most developers (and I mean real developers with real deadlines that dont have time to deliver two solutions like gmail) steer clear. Anyway, Ajax is great for all us sighted developers with tonnes of time and cash.

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff