Is client-side UI rendering via Javascript a good

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

The YUI Theater has a video that I think is highly relevant to your question - I strongly recommend watching it

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

The title is a bit misleading, but he actually talks about the very issues you're facing.

Answer 2

I've done it by hand. It was kind of a pain, but there is some upside. This is only appropriate for rich Internet apps where a fallback makes little sense. I think we'll see more and more apps that require JavaScript, especially after frameworks like Cappuccino Atlas arrives.

Answer 3

I like to implement a hybrid approach. When a page is first requested, it should be populated with as much information as you can infer from the URL/Querystring/Post. And then any subsequent state changes can be queried for and updated using Ajax.

A lot of people tend to take the approach of simply loading the page, and then letting the javascript/ajax do the work of loading. This results in the client waiting for the page to load, and then the client waiting for the data to load.

Much better to just let the server do that initial data load and populate all the UI elements.

Answer 4

ExtJS, YUI, dojo... frameworks that basically offer a hand in implementation apps like the one you're describing

We(at my workplace) used such approach successfully for many many large & small scale apps... In general basing most of our app on ExtJS+jQuery, in some cases on dojo(Zend Framework(if you care about PHP world at all) provide handy integration with dojo elements)

If it is not abused and used just for the sake of using it or bumping the coolness factor - it is an awesome tool.

With proper design it neither heavy nor slow as an approach per se.