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:
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 (
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!