March 10, 2009

For this post I thought I’d share with you a recent response I made on the GWT forums regarding the question: “Which is better performance wise; CSS or in code styles?”.

Donald Knuth is credited as once saying “Premature optimization is the root of all evil”. I think the question asked here is well intentioned, however misguided. Whilst performance is important we’re often blinded by it’s supposed benefits as developers and forget more important concepts like separation of concerns. This is the key design principle that should be considered here, not performance. As you’ll also see though there are some nice performance benefits in taking steps to keep things separate.

Setting a style in CSS allows for the presentation aspects of the application to be nicely decoupled from the application code. Using CSS over code however is beneficial for a number of reasons:

1. It reduces the amount of code you have to write.

This cannot be understated enough. In browser land less code == better performance. The vast majority of AJAX/RIA apps performance shortcomings have nothing to do with running code, but rather the time taken to download and parse your JS. So by doing the right thing in keeping your different concerns separate you actually win when it comes to performance.

2. It keeps your code clean and focused on solving the business problem at hand.

When it comes to maintenance (which we all learn at uni is actually 80% of any application’s total cost over its lifetime) there’s nothing worse than trying to pick your way through a veritable minefield of presentation related cruft in an attempt to fix a logical problem. One wrong move, one misunderstood line and BAM, you’ve broken your carefully crafted interface. This is part of the reason why separating your concerns is so valuable, in a way it’s your insurance against complexity. If you can adequately separate things you’re effectively confining the risk to a single discrete, and usually well understood unit of functionality.

3. You can modify the look of your application without touching your code.

From a straight development perspective this is a real time saver. If you’re like me and have to develop large parts of your app in-situ inside an existing web application you don’t have the luxury of using the Hosted Mode browser for the home stretch. If you insist on putting all of your styles inside your code you’re stuck with a total recompile (which for me takes up to a minute) before you can see if your change was successful. Painful.

Further down the track if your client changes their mind and wants something changed, say a particular color or font, it’s really nice if you can make the change without a recompile. With every code change/recompile there’s always the possibility that you will break something that was previously working. Not good when you’re working on something mission critical, or high availability.

4. CSS style are computed natively.

Again this is a performance win. Anything that can be carried out natively by the browser is going to win over interpreted code. Sure some JS VMs like Tracemonkey and Squirrelfish can analyse your code and improve execution speed (and in some cases surpass native performance), however the issue here is that this on the fly optimisation doesn’t come free. This is really only beneficial for repetitive or frequently run pieces of code which may be aggressively optimised. Styles for the most part, bar dynamic ones (e.g. setting width in animations), don’t change often enough for this to be of use.

A common strategy which I use in real life is to apply classes to absolutely everything that could require styling. Then when I start the process of pulling together the look and feel I simply load the page, start analysing the page structure and the class names, then write my CSS. You’d be surprised how much flexibility you have and how quickly it all comes together.

May 28, 2008

I had a question from one of my coworkers a few weeks back about some basic OO techniques in JavaScript. Seeing as this is a key question from most people getting into JS from a classical OO background I thought I might just share a powerful little concept called the “Module Pattern” to get you all started.

The module pattern (first identified by Douglas Crockford) exploits the fact that JS only has one kind of scope: function scope. Forget blocks, or any other kind of scope resoultion techniques you might know from other programming languages – it ain’t here. JS allows you create functions within functions (i.e. nest them), and hence function scope is also nested. Any nested function can see anything in the parent function and so on up the tree. It does this through the use of closures which is far to big a topic for this short article, you’ll just have to accept the fact that it works.

Okay so why is this important? Well JS has a major flaw (some would say feature) in that it doesn’t have any sort of PPP (public, private, protected) functionality. Everything is public. Everything. So how do we achieve any sort of meaningful encapsulation you ask? Isn’t information hiding critical to the design principle “open for extension, closed for modification”? Well the module pattern is one solution to this problem.

I know that this will completely weird out some of you OO purists, but when JS is the only thing you’ve got (e.g. in the browser) it’s a pretty useful technique for gaining some sort of PPP control over your objects API.