Server vs Client-Side Rendering

January 5, 2012

I’ve come to a strange realization today. Several industry leaders and even some companies (http://d8p.it/17392,Leaving_JSPs_in_the_dust:_moving_LinkedIn_to_dust.js_client-side_templates_%7C_LinkedIn_Engineering.html) are moving to using Javascript and related libraries to move most code to the client for high scalability solutions.

In thought, that is a great idea. However, it’s a bit of a strange paradigm. Initially, there was only a handful of languages to program in. Then, there was only a handful of languages to write server-side web applications in. Then, tons more came to the scene. Why? Because no one language fits all cases. Some are more optimized at specific use cases and make sense. As a Java guy, I’ve used several of these, but each has their place. JSF works great in form-heavy, intranet sites. Grails works great in dynamic, database-driven systems. Struts has its place. Library Xyz has its place.

If the world moves to rendering more code on the client via Javascript, in a sense, we go backward (ok, not really, but bear with me). There is only 1 language on the client side: javascript. Yes, Google exposed us to Dart, but realistically that will never mean anything because IE, Opera, Safari, etc will never support it, just as Mozilla never supported Visual Basic on the web. Javascript is the defacto “scripting” language on the web and always will be (unless someone manages to convince the entire industry and the entire world otherwise).

Yes, I know there are a ton of Javascript emulators (coffeescript, dart to a degree, objective j, etc), but it’s still javascript. There are even a ton of libraries in JS to simplify it so you don’t feel like you are using JS. In the end though, it’s all javascript and you are bound to the browser support, performance, and bottlenecks (even more so in some cases where emulators make things easy but use crazy hacks in javascript to make it work resulting in expensive operations).

Anyways, I’m not trying to advocate one way or the other (I, myself, have not really made up my mind, yet). I just found it strange how the progression of web applications was driven server side by the advancement of new languages and methodologies. To purely go client side, you are almost binding yourself to a single language: Javascript. Worse yet, there is no real progression possible other than emulators, which always scare me (I prefer having control of what something is doing rather than a cross compiler or emulator doing it for me). Maybe in a few years, emulators and javascript will advance enough that we can have different languages and libraries that are highly performant making you be able to choose the right language for the right use case and job. Only time will tell.

2 Responses to “Server vs Client-Side Rendering”

  1. Same argument as on fat-client vs thin-client.

    I prefer to have fat-clients. As they can do some processing that are currently been done on server’s side, like rendering, formatting and other data conversion/modification. Thus offloading the server.

  2. Moving to Javascript fat client is step backward? Historically, old computer terminals with big servers were based on similar principles as today thick client. So we cannot say which architecture is step forward, or backward, it depends on situation. I prefer fat client, because there is better state control, caching and advanced user interface.