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

Tools such as Google GWT do what you describe - render much of the client side in javascript. Some of the coarse-grained layout still gets down using HTML, but the interesting bits are done dynamically, client-side.

But GWT uses generated javascript, not hand-written. Doing this by hand is painful.

Answer 2

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.

Answer 3

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 4

I think it's horrible. Hard to develop. Hard to debug. Hard to get the functionallity you want. I prefer to keep web applications as simple as possible, and go for ordinary GUI applications when anything more complex is needed.

Answer 5

Your assertion that web developers can now "pretty much assume their Javascript code is working" is a tough one to agree with. In my experience Javascript is almost always a black hole sucking all the time and energy you can supply it. Frameworks like Prototype and Script.aculo.us have made things MUCH better, but they are not yet as hardened as your question assumes.

The two main issues are one, browser support and two is development time. You are relying on an application you cannot control to handle the bulk of your app's work load. The fact this can be broken with even the most minor update to the browser would concern me. Generating HTML server-side mitigates this risk to a large extent. Development of a rich Javascript front-end is time consuming, difficult to debug and equally difficult to test across the wide array of available browsers.

While those concerns are real, the fact you can achieve some fantastic User Experiences via client-side Javascript cannot be ignored. The frameworks I mentioned earlier expose functionality that was not even dreamed of a year or two ago and as a result make the up front development price in some cases largely worth it (and sometimes significantly shortened when the frameworks are implemented effectively).

I think there are applications for A Javascript-powered UI, as long as the decision to go that route is well thought-out. We would not be discussing this on SO were it not for the fact that the UI potential using this strategy is awesome. Web-based applicationsusing web-based data are perfect candiates (RSS, REST Services). Applications hitting a relation database or complex Web services repeadly are going to by necessity maintain a tighter coupling with the server-side.

My 2 cents.

Answer 6

If I understand your question correctly I think you're referring to the kind of development one does with something like ExtJS. With Ext you no longer really write any HTML, but rather design the entire application in mostly JavaScript, using techniques similar to development GUI apps on the desktop.

For the most part modern toolkits have almost eliminated most browser quirks. Although you can certainly still run into cross-browser rendering issues occasionally, it's not nearly as a big of a problem as it would be if you tried to write all the JS yourself. Speed should be acceptable even in IE6, although you will general get better performance in a recent version of Safari, Chrome or Firefox. (I don't know enough about IE7 or 8 to comment).

You brought up a valid point however about URLs and their share-ability. Even outside of the use-case of sharing data this is important for bookmarking locations within the application. There are techniques available for storing application state and being able to reconstruct it, but as far as I know it's still not easy to do. For this reason it makes sense to avoid rich web applications in situations where they are not necessary. Simpler web applications can be simpler to debug, test and maintain.

That said, there are situations where rich web applications make a lot of sense. For example a lot of internal enterprise desktop applications can be rewritten to be rich web applications. They can provide similar look and feel, widgets and interaction patterns as desktop applications making the transition to a web application easier. External facing applications that involve manipulating data (like email/news readers, accounting applications, etc) can also be a great fit.

Answer 7

For internally consumed line of business apps where you can control the desktop, javascript makes sense.

For external / public facing apps where you have no idea what browser your consumers are using, keep it dead simple and use as little as possible.

When you say that Javascript just works now due to the frameworks, that's not exactly true. IE 6 is still in widespread use, as is older Safari. Even FF 2.x, and 1.x to some extent, has decent share of the consumer market.

Along with that, not everyone has high speed internet, which is pretty much a requirement for a lot of these frameworks. Further, although most libraries work with IE 7, it's a dog for most operations.

On the subject of library size, we have a number of .net controls which like to inject up to 1MB of javascript to the client. Trying sending that to Grandma.

Lastly, phones are picking up users as a primary internet access device. Unfortunately, their cache size is small and, for the most part, those cool javascript things don't work too well.

Answer 8

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 9

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.

Disavantages:

• 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.

P.S. Not really related to this topic, but one big advantage to using ExtJS turned out to be cross-browser debugging. I spend almost no time on that now. The framework pretty much solves that problem. It's magical.

Answer 10

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.