The title of this post was intentionally chosen to raise some eyebrows – after all we all know that in most cases (I’m taking the likes of Rhino out of the equation, same for applets) the former resides on the server side while the latter is used as a client-side language. So why would someone have a go at comparing them?
I guess the post really is more about questioning whether we should move most of the processing on the server side or whether it is a good idea to leave some of this to the client side.
Let’s start with some basic example: showing the user the local time and date. (By local I mean local to the user!)

If we intend to do this server side we’ll do something like this:

Date d= new Date();
DateFormat df= ... //prepare the format we need the user to be in
//we might also take into account the user is in a different timexone and add or substract hours etc
out.print( df.format(d) );

At this point we have created 2 objects in the server JVM which will be discarded once the response has been sent back to the client – and as such the objects will be subject to garbage collection. In an application when we get tons of such requests we are putting a lot of stress on the system’s memory recycling as we’ll end up with lots of memory that needs to be reclaimed very often. Let’s look at the solution that involves JS:

<script type="text/javascript">// <![CDATA[
document.write( new Date() ); 
// ]]></script>

That’s it! No extra memory consumption on the server, no extra cycles needed for computing timezone differences, or formatting the results! Even more since the above contents is static, you can offload that to a simple Apache instance to serve the contents and take the burden off your application server. And if you need to compute the user local time for instance – you could as I said have a function which based on user profile settings adjusts the local time and stores it as an attribute in the user session – or you could use some javascript to create an instance of Date then pass that to the server side via a simple Ajax call (and from there one once you get that date you just store in the user session and use it as before). It’s interesting to see that simple things like these are still done in a lot of cases on the server side – and there’s hardly ever a clear reason for it, but even though computing user local time might only take a couple of variables and only a few CPU cycles, multiply this by 1,000’s of users and all these small numbers add up.
Another example – which is common in the web world is writing back to the user a message comprising of a concatenation of a few session variables – for instance if you say open an email in your web mail system the header might show you something like this: “received from John Doe (john@Doe.com) on 1/January/2011”. Looks simple enough and any server side developer will probably use a string templating mechanism (String.format, Velocity engine etc) and pass in the sender name, email address and sent date to produce this script-nothing unusual about this. But under the cover in this example you will employ 4 strings (the template, sender name, sender address and sent date) and based on these you produce a 5th one which gets displayed to the user. But what if you take a different approach and you just dump just 3 of these variables (sender name, email and sent date) to the page in a format your javascript can “understand” (eg JSON) and let your scripts concatenate these and present exactly the same message to the user?you’d argue that really this only saves you one string – and in this example it is true- but think now how many other things in your app can be changed like that so you don’t create an object to serve just for the purpose of that request? If we look at the above example what if your application shows customized buttons like “reply to john Doe”, “archive john Doe’s message”, “report john Doe’s email as spam” – all of these messages are created server side for each message you view, and while the memory consumption is small the fact that there are loads of them means your GC will work pretty hard to recycle these. Looking at the above example for the message and buttons you’ll end up creating (and then dumping) 4 strings for each email viewed; taking the approach I’ve described means you don’t create any!
I do accept the argument that a web based mail system needs to be used by a variety of clients – some which might not have JavaScript support – in which case you can’t avoid building everything server side. But there are a lot out there which only target and require “modern” browsers – and as such this approach would work just fine.
Historically a lot of the processing has happened server side to separate the business logic from the presentation layer. Also at the same time initially javascript support in browsers was rather poor and not standardized. But I’m not advocating changing the business logic to the client side – in fact everything I talked about earlier on us only to do with the presentation layer! Also let’s remind ourselves that browsers made a huge progress when it comes to javascript – after all we have nowadays frameworks like jquery and prototype and scriptaculous working cross browser and taking care of everything else for you, we have browsers that even though need a few hacks here and there do support largely the JavaScript standards. So if you know your clients, and even more if you can enforce it (and most corporate products can enforce this – by rolling out ie9+ across the enterprise for instance) then it’s worth wondering yourself if you might not be better off changing some of the way you do things in your app and allow some more processing on the client side? After all browsers and PC’s have come a long way and asking the browser to do a bit of string concatenation is nothing nowadays and the speed difference from doing that server side or client side are negligeable. And if you can offload some of your processing server side to another component (be it the client browser) then you should. I appreciate that saving 4 megs of RAM is not much nowadays – if anything it’s too much hassle to chase for that memory! – and if at first glance all you can get from your web app is save some memory then moving things client side is not benefit you that much. But if you reduce your churn rate of new object creation then that is a major achievement – because your GC will kick in less often for once and you’ll have less time spent for “kitchenware” and more time spent on what your app was designed to.