Dev approaches to complex JavaScript UI's [closed]

Question

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?

Thanks!

Answer 1

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…

Answer 2

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!

Answer 3

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.

Answer 4

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.

Answer 5

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.