Moving your web app to the client-side: Advantages

A few blog posts ago, I talked about how AJAX is shaping the architecture of web applications. Specifically, the combination of the JavaScript DOM, Event Model, and the XML HTTP Request object allow us to implement components that would otherwise reside on the server-side. For example, instead of submitting a form to the server and retrieving an entire page as a response, we can intercept the submit request by using a custom onSubmit Event Handler. The JavaScript control logic then determines what database communication is needed, and passes the request to the server side using the XML HTTP Request object. It then receives the data from the server and processes it appropriately, updating the application state.

In theory, we can minimize the server-side responsibility to that of a Security Manager. This would be an object whose sole responsibility would be to determine whether or not to pass on the request to the database. The Security Manager would be implemented using a variation of the Mediator design pattern.

However, going into implementation details of this client-centric approach are way beyond the scope of one blog post. Instead, we're going to talk about its advantages. To aid in this process, I've included the original figure from my last blog post below.

1: Reduced bandwidth usage and server load

Arguably, this one of the most compelling reasons to move as much of your web application to the client-side as possible. First, you are saving massive amounts of bandwidth because you are essentially replacing every page refresh (in the order of tens of kB) with an exchange of a few bytes of data (in the form of simple, JSON-formatted text strings). Second, the control logic no longer resides on the server, so you'll save huge amounts of processing power. You're essentially leaving it up to the client to process their own data. The server is only left with the task that it's unconditionally needed for: controlling and accessing the database.

2: More responsive application behaviour

This is a frequently-mentioned advantage of any AJAX-enabled web application. By being able to pinpoint what element in the page to refresh, we can make the application more dynamic and pleasant to use -- no more having to put up with the entire page "blanking out" and you having to wait in frustration while most of the same stuff gets loaded again from scratch.

3: Easier collection of user submitted data

Online form submissions + browser back/forward buttons = pain in the butt!
No web developer can ignore the truth of this simple formula. With client-side scripting, we have much more control over both variables on the left hand side of the equation. Form submissions can be intercepted with the JavaScript Event Model, and browser history can now be controlled with frameworks such as RSH and Dojo (see this AOL article for details).

4: Easier web app customization

No matter how much planning you put into your web application, you always will run into customers that want some obscure bit of functionality that was overlooked or prematurely dismissed. Customization is inevitable, and taking a client-centric web development approach means that you will be more prepared for it.

Client-side changes are always easier to implement because you will never need to halt the server to commit the updates. Furthermore, you can adopt a very fine-grained approach: the Template Loader in Figure 1 could be configured to load distinct HTML, CSS, and JavaScript pages for each customer. In doing so, you are achieving customization in three dimensions: layout (how information is laid out in the browser), presentation (how the information is decorated), and behaviour (how the browser reacts to user input).

It's important to note that each one of these building blocks remains completely static. The server side script does not dynamically modify them in any way (the JavaScript control logic has this job). Because they remain static, customization becomes easy to manage -- your software developers can be highly specialized in one language each versus having to be "jacks of all trades."

If I've succeeded in getting you excited about client-centric web applications, I should warn you that it may be short-lived. I plan to come back tomorrow and present the other side of the coin: the disadvantages, obstacles, and plain impracticalities of moving your web app to the client side.