Is client-side UI rendering via Javascript a good idea?

Question

The "classic" approach to web development has been for some time a thin client and a thick server: the server generates HTML and spits it out for the browser to render only. But with current browsers (and also due to the availability of good libraries and frameworks) Javascript now works. Web devs can now pretty much assume that their Javascript code will work and stop bothering.

This certainly opened new possibilities for web development. Apps could now be composed mostly of HTML content returned from the server and rendered by the browser with some UI manipulation being done client-side. The client could even query the server for fresh data for updating parts of the UI. But can we go down all the other way? An app can certainly be designed as a server that spits only the most minimalist JSON glued together to a thick Javascript client responsible for building and controlling the whole user interface. Yeah, this approach can seriously break URLs to the extent that people can no longer send pointers around, but it is certainly possible to design your way around that (and for some apps, like e-mail and feed readers, this doesn't even matter).

What do you think? Have you ever tried that approach? Do things get too slow? Are modern browsers capable of dealing with that amount of Javascript code? Are there any significant differences between browsers implementations that still bite the unadvised developer even with the latest libraries? What kinds of applications do you think this approach is suitable for? Is it actually suitable for anything?

Answer 1

I'm on the tail end of building just this sort of app. It's an ExtJS GUI on top of Zend Framework JSON-RPC web services, implementing an iGoogle-like gadget portal.

Advantages:

• Very responsive UI, ExtJS gives you a great user experience.
• Very predictable client-server communication. Everything's json (easy to debug). There's standardized error handling inherent in the API (at least that's how I designed it).
• The front-end is replaceable. I could write a C++ app on top of the same server back-end. Separating front-end and back-end across client-server lines means they're easier to test independently.
• You get to live and breathe javascript, which is great if you like it.

Disadvantages:

• You have to live and breathe javascript, which sucks if you hate it. In our case this meant a major retraining of the developer team because we were PHP-heavy.
• Everything lives in a single long-lived DOM, so you have to stay on your toes with memory management and making sure stuff gets cleaned up correctly. Also, loading too much UI makes IE go "ow, ow, you're hurting my brain".
• There's no running a quick query to fetch an option in the middle of generating the UI. The program design constraints of living on the client are daunting at first. You get used to it, but it's a bit of a hurdle.
• Loading all that javascript means your users need to have fast connections and modern browsers.

The driving reason for us to do this was to deliver a better user experience. Users expect a desktop-like experience, and you can't deliver that across a server roundtrip. We get to deliver that now, but there's no denying there are big challenges with an approach like this. Overall I'm satisfied though.

Update (september 2013):

Still using this architecture and still thinking it's the right architecture if you are building a genuine web application (not just a web page with some dynamic features). Our team and product is now much larger (nearing 500.000 lines of code), but the architecture has scaled without issue. There are now many really good scalable javascript frameworks (angular, ember, ...), so it is easier than ever to adopt this way of working.

Because @rwoo asked, some challenges that we still have:

• On-demand loading of js code turns out to be a trickier problem than foreseen. It's important to get this part right in your architecture.
• We have had to integrate automatic jshint validation in a pre-commit hook in subversion because js is way too tolerant of syntax errors and you often don't notice this until the product reaches the customer.
• Because the database is on the other end of a web service request, you have to carefully design your web service API or you will end up with lousy performance due to waiting for too many XHR requests. This is solvable, but challenging, and it doesn't get easier with time.
• While with the right framework cross-browser issues are minimized, they don't go away entirely which means that you need to test in all browsers, all versions. This is so much work that you have to automate it using something like selenium, and as it turns out this is more difficult to do with a client-side rendered UI than a server-side rendered UI.