Moving your web app to the client side: Disadvantages

Two posts ago, I introduced a high-level design approach that would enable you to move most of your server-side application to the client side. In my last post, I discussed the various reasons for doing so. In this post, I talk about the disadvantages of this web architecture concept.

1: Source Code Visibility

As client-side code is not compiled, but interpreted, all of your JavaScript code is accessible to anyone who runs your web app. Clearly, this makes it easy for a competitor to steal your entire implementation and put it on their site.

A partial solution to this would be to move any proprietary algorithms that implement trade secrets (e.g. a product suggestion feature) to the server side. Access to the algorithm's functionality would still be passed as an AJAX request through to the Security Manager, which would in turn communicate with an object containing the algorithm locally on the server (possibly implemented as a Strategy design pattern). This kind of setup allows controlled access to the functionality without exposing its internal details.

I should also briefly point out that JavaScript obfuscators exist (example with discussion). These change the formatting of your JavaScript source code to make it completely unreadable to people (while still being readable by the JavaScript interpreter).

I am against this idea because it attempts to make JavaScript into something that it isn't. The Engineers at Netscape (or more specifically, Brendan Eich) had a reason to make JavaScript an interpreted language. It's executed on the client-side, in a web (untrusted) environment, so users have a right to see the code that's being executed. It's not surprising that I got predominantly anti-spam references in my web search on "javascript deobfuscation".

2: Inconsistent Performance

Another issue about delegating most of your web app execution to the client-side is that the code is not running on a homogenous hardware platform. With a web app that exists solely on the server side, your code always runs on the same machine (or group of machines if load balancing is implemented). You also can keep close tabs on the machine (AKA server) to make sure available memory and processing resources are within norms.

Theoretically, you could use JavaScript to get a rough idea of client-side capabilities by writing functions to get the screen resolution, or measure the elapsed time between a request / response cycle. Measuring available memory or processor speed, however, is not a viable option. Besides, even if you were able to determine that the client machine isn't good enough for your web app, what then? You would either have to turn them away, or code an entirely different version of the web app for these less capable clients.

3: Browser Differences mean Superfluous Code

Unfortunately, browser usage these days is divided mainly between Internet Explorer, Firefox, and Safari (with some smaller players, such as Opera). Even if we stick to the big players, we have to write additional code solely to provide cross-browser compatibility.

Fortunately, this becomes less significant the larger the JavaScript code base. The reason is because the portion of the code that accounts for browser variations does not grow as your application gets larger. Furthermore, if you go with a toolkit like Dojo, cross-browser support is already handled for you.

4: Reliability of Cookie Data

JavaScript cookies offer a handy way of preserving application state on the client-side. JSON allows for advanced datatypes to be stored in cookies, and if the user turns cookies off, JavaScript is able to detect this and go to a fallback plan.

However, we venture into dangerous territory if the server always trusts the cookie contents. Imagine if you implemented a shopping cart entirely on the client-side, and didn't verify the total charge with the order contents on the server side. The mischievous user could modify the cookie on their computer (aka cookie poisoning) just before it's sent to the server, thus giving themselves a "custom" discount!

It is unnecessary to suspect all data in the cookie to be tainted. However, a defensive programming approach should be the main focus whenever the server uses cookie data.

Conclusion

Yes, that's a long list of disadvantages. However, looking back on the list, they seem more like obstacles, or conditions that determine how much of your web app should be on the client side.

1: We discovered that algorithms that embody trade secrets should always stay on the server-side, and access to them should be exposed in a controlled manner.

2: We learn that processor or memory-intensive operations should remain on the server, as a high-performance client-side platform is not guaranteed.

3: Uncovers yet another reason for going with an AJAX framework (versus do-it-yourself) -- cross-platform compatibility becomes a non issue as it's taken care of by the framework for you.

4: Never trust data coming from the user (including all cookies)! Client-side validation is only meant to be there for convenience; it should always be shadowed by server-side validation to protect the backend system.

After all this, I believe that a web application architecture where the majority of the code lies on the client-side is still viable in some cases. It will be interesting to watch how JavaScript's role will develop, in light of these observations.