I am trying to understand the landscape of different approaches, and best practices, around the development of complex client-side JavaScript.

I'm not sure what to label this class of application, perhaps heavy AJAX or RIA (but not plugins like Flash/Silverlight). I'm referring to web apps with these characteristics:

  • Emulate rich/native desktop UX in JavaScript
  • Contain most/all behavior in client-side JS, using the server as a data-API (JSON/Html-Templates).

This is in contrast to using the web-server for the UI rendering, producing all HTML in a page-refresh model.

Some examples are:

  • Google Docs / Gmail
  • Mindmeister
  • Pivotal Tracker

As we move forward into HTML5, I can see this style of RIA development, with heavy JavaScript, becoming ever more common and necessary to compete.

QUESTION: So what are the common approaches emerging around managing these kinds of heavy JS developments?

Client-side code, as an app grows in features, is fiendishly complicated. There are problems scaling a development effort across multiple teams with raw JS (or so I hear, and can well believe it).

Google has approached the problem by building GWT that compiles from a higher level language (Java) to JS, leaning on the existing development infrastructure that the higher level language has (Eclipse, strong-typing, refactoring tools), along with abstracting browser compatibility and other issues away from the developer.

There are other tools, like Script# for C# that do something similar. All this puts JS more in the role of an IL (Intermediate Language). ie. "You never really write in that 'low level language' anymore."

But this 'compile to JS' is not the only approach. It's not apparent that GWT is the dominant approach...or indeed will become it.

What are people doing with rich-client JavaScript? Some orienting questions:

  • Are most shops crafting JS manually (atop libs like jQuery et al)?
  • Or are there many many different approaches, with no clear best-practice emerging?
  • Are most shops avoiding RIA scale development in favor of the simpler to developer server-side/page-redraw model? If so, will this last?
  • Is compiling to JS perhaps an emerging future trend? Or is this just wrong headed?
  • How do they manage the complexity and refactoring of client JS?
  • Modularization and distribution of work across teams?
  • The application, enforcement, and testing of client-side patterns like MVC/MVP etc.

So, what are the emerging trends in this heavy-JavaScript and HTML5 future of ours?


  • Zimbra relies heavily on client side js to emulate desktop environments. Commented Nov 13, 2010 at 22:46
  • Thanks. Do you know how they develop their JS? Hand crafted, or higher level tooling? Commented Nov 14, 2010 at 6:50
  • This answer to similar question summarizes options pretty well: stackoverflow.com/questions/218699/… Commented Feb 28, 2011 at 18:22
  • 1
    Google+ is a heavy use of GWT I believe (which is expected... seeing as it's from Google) Commented Aug 22, 2011 at 14:58
  • Too bad this question was closed :( ...IMHO it should be reopened
    – dagnelies
    Commented Nov 4, 2014 at 15:06

5 Answers 5


Most of the Web apps I see (and Web devs I've talked to) who are moving in this direction are using jQuery as their base.

The whole reasoning behind GWT (and similar multi-level languages) is that JavaScript is too flakey/too fragile/too changeable for "real programmers" to use. But if you have a framework handling the flakey/fragile/changeable bits for you, then there's no reason to add on that extra layer of complexity.

Just my opinion…

  • I kindof doubt that any framwork can take out javascript's "fragility". It's dynamic nature makes it very difficult to ensure consistency and prone to runtime errors. It suffices that a json attribute was renamed somewhere and not repercuted the whole way down to break things. ...It's not a problem with typical small scripts, but in complex RIA with thousands of LOC, this can quickly happen, and quickly go unnoticed. No framework is able to avoid that.
    – dagnelies
    Commented Nov 4, 2014 at 15:04

I would say GWT is risky. Once you decided to use it you're stuck with it. Basically it means that you treat your markup, DOM and some aspects of CSS as an execution environment. It's getting really hard to mix manually written JavaScript with GWT as your client code becomes more and more sophisticated. GWT has native methods but those are quite limited in terms of possible applicability. That's a big trade off and it's a big bet.

Google tries to sell GWT as a very fast X-platform execution environment with a decent server-side integration. But as others already pointed out it's no longer the case - JQuery and YUI are as fast if not faster. And it's much easier to profile and optimize your pages when they are assembled manually so you have a full control over CSS, markup and JavaScript.

GWT tries to hide the underlying platform from you which might actually be a wrong way to do things. A lot of so-called component web-frameworks did the same. You were supposed to write ambiguous XML-derived code with EL and custom tags thrown in. The output would be a mess of poorly formed HTML with small pieces of crappy JavaScript sprinkled all over the place. Pages were slow, buggy and totally unmaintainable.

In our current project we use Stripes - a low-level action-based framework, - and JQuery on a client side. It's very easy to do Ajax once you clearly see all pieces of a puzzle: here's your Server-side code which operates on data. Here's your client-side code - for data retrieval and for making things happen on a pages. Here's your CSS, here's your markup, here's your templating - everything is clean and decoupled. Easily extensible, hackable, tunable and debuggable. I love it.

I love JQuery with it's attitude towards speed and simplicity. I love YUI3 for modularity and comprehensive widgets. I love YUI CSS for giving me consistency across browsers. I love JavaScript for Good Parts. I love Java for letting me Get Job Done.

Just KISS, and you'll be fine!

  • 2
    And BTW, Google doesn't use GWT for GMail - they use their Closure library. Commented Nov 18, 2010 at 16:05
  • 1
    Really appreciate this analysis of the risks around GWT, and compiling from higher level languages in general. Commented Nov 22, 2010 at 19:21
  • 2
    I think I agree with Andrew. You don't need the higher level frameworks if you understand JavaScript. ASP.NET WebForms for example is such a framework that uses XML and custom tags for creating things like wizards and popups for a more simple programming paradigm for someone with little experience with the web but more experience with Windows Forms. To try keep a paradigm. But ASP.NET MVC is becoming popular and the standard IMO, because it's closer to the web - it's paradigm fits reality. Commented Aug 22, 2011 at 15:06

I have heard these called "Single-page applications".

This is a new environment, and the rules are not totally written yet. I worked on a relatively major single-page application last year (2010), and these are the tools we used.

The back end was Java, using servlets to provide a JSON service, which the page used to ultimately submit the prepared order. This service was also used for some validation steps, and pricing.

The front-end code was javascript. We used jQuery to do manipulation of page elements, Pure for templating, and RequireJs to break the code into modules. (RequireJs' build tool was used to provide more optimal downloads.)

We wrote our tests using qUnit, and had a jUnit test which used htmlunit to run each qUnit test, then scrape the output for results, and pass or fail based on the qUnit pass/fail status. Those got added to our jUnit tests for the back end, and rolled into our ci, using Hudson/Jenkins.


I work on such an app, built on top of Ext JS. The app is organized modularly. Different modules are implemented as self-contained components that clean up after themselves when they are removed from the Ext component hierarchy. On-demand loaders load additional components right before they are needed (one js file = one component).

I've found that this approach is not that hard to scale. The only real limits I've run into are related to having too many DOM elements in the tree at the same time in IE. The solution there is to strategically unload hidden parts of the application. Because all DOM manipulation occurs via the Ext component hierarchy, the DOM is almost fully abstracted away, and development remains straightforward.

  • ExtJS is really interesting to look at (thanks), seeing that Sencha creates both native JS and GWT libs (ExtGWT). It seems they're hedging the bets. Commented Nov 15, 2010 at 17:16

Personally I think that frameworks such as jQuery are vital not just to deal with variations across different browsers but also to tuck those differences away so that they're not adding noise to the code. Tools like GWT, Websharper and others take that further and definitely have a place but I wonder if it's just an extra layer of indirection in most cases.

Something that I'm suprised that no-one has mentioned is unit testing. It's now generally accepted that complex server side apps should have automated unit tests and I think that the time has already come where the JS in RIA apps is complex enough to need unit testing - together with the architecture/code that makes that possible.

However, unlike with complex server side apps, my gut feeling based on what I see and hear is that the vast majority of complex client side apps have absolutely no unit testing (I'm not talking about selenium testing here, real unit testing).

I think that the next emerging trend will be the introduction of unit testing (and code that is unit-testable). Having just completed a project with a moderate amount of non-unit tested JavaScript I'm hoping it will be the last.


Not the answer you're looking for? Browse other questions tagged or ask your own question.