JavaScript Ain’t Magic, Joe
Understanding when to use JavaScript (and when to use something else) is a skill every web designer needs to get a handle on – and there’s always that grey area of “it depends” where you know the targeted users have the appropriate technology, or the application is such that it could be a reasonable expectation. Those cases aside, JavaScript ain’t magic, Joe.
It’s Our Design Problem
The key thing to take away from this post is that JavaScript runs on the client side. The server doesn’t run the script, the client does. That means in most general real world situations you, as a designer, have to consider the wider case of whether or not the user can be expected to have that capability on their machine. Seriously, what if they don’t have JavaScript enabled (I’ve heard statistics over the years that this demographic can be as high as 10%). And, if they do have it, what version? This isn’t just a binary black and white answer – maybe JavaScript is disabled because of security concerns at their company; maybe they don’t have the latest version; and, maybe they’re not in a position to change the state of that paradigm right at that moment. So, you can see that it’s not their problem – it’s our design problem.
It’s a part of our job to design around constraints and limitations in elegant, intelligent ways.
Just Because You Can Do Something…
The dumbest thing ever said to me by an academic was this year at an assessment for a 3rd Year Bachelor of Computing unit – KXT301 Software Engineering Project A. Our code did all the major validation of a contact form in the PHP (Hypertext Preprocessor) on the server side – we actually used Jeremy Keith’s Hijax technique. However, a 4th Year Honours student invited to contribute to assessing our team’s work kept asserting to me that all our validations could have been achieved in JavaScript – WTF? This included checking the MX value, port 25, and anti-spamming checks using regular expressions – is this a real user with a real email address that is active? He marked our project below a pass mark for his worthy opinion (I still got a High Distinction). Now, when you think about that in the real world do you appreciate that any spamming form hijacker isn’t going to realise that and just turn off JavaScript? Please tell me that everyone can understand the difference between server side and client side validation… because that was academic bullshit! But it’s something we see a lot in real world web development as well – simply not considering the whole picture.
Just because you can do something with JavaScript doesn’t mean it’s the appropriate technology for the task.
We Have No Control Over the User’s Environment
So, JavaScript ain’t magic. It’s got a strong role to play in what we do but we have to realise that we have no control over the user’s hardware / software configuration so a large part of what we do as designers is to work smarter – we care about these what ifs. We use JavaScript appropriately in the context of the big picture, instead of just saying wow cool this is snappy – remember the DHTML (Dynamic HTML) crap from a few years ago?
When Not to Use JavaScript
The second point then is that JavaScript is also not the magic bullet for some things. Understand the flaws of running code on the user’s computer instead of the server – would you use it for a shopping cart on an e-commerce site? No. Would you use it for search on an information site? No. In fact, you’d be a little naive to use it for anything critical to your site’s functionality or for security or for processing information like the prices of products in a shopping cart.
When to Use JavaScript
So when to use JavaScript? As the behaviour layer of your website it’s obvious that JavaScript has it’s place. You can use it wisely to enhance the user experience, you can use it to pre-validate input fields to save unnecessary page refreshes for minor form errors, and you can manipulate the DOM (Document Object Model) to do lots of other great things. Just not site critical things. And you should do JavaScript unobtrusively – in external stylesheets, without inline event handlers, use object detection before running the script, and do your work via the DOM. Think about the experience for users who don’t have JavaScript. Consider the broader question of usability – is this just a swishy navigation enhancement that gets in the way of the user’s goal, or does it enhance and speed up their progress?
What About Ajax Applications?
Yes these have their place. But Ajax (Asynchronous JavaScript and XML) should be used responsibly. If you’ve got an application where user response times could be slick and you’ve thought about how to deal with issues like updating the user of page changes, and you’re aware of the down side – hey Ajax can be brilliant. But the same rules apply. If you’re going to use some fancy Ajax widget on your site like a fancy calendar – the same criteria applies. Usability? Accessiblity? No JavaScript? Wrong version JavaScript? Security? Efficiency? Necessity? And, is there a business case to support it?
No, It Ain’t Magic
Used wisely JavaScript is arguably the most exciting layer we get to work with as front-end web designers. We can use it to create slick, magical experiences OR we can blow our site users away with insecure, unusable rubbish. It’s our job as designers to understand the difference. The key points are that it’s run on the users computer (client side), and the flow-on is that we therefore have no control over the environment. For resources on writing great JavaScript and using it wisely the best places to go are:
- Jeremy Keith on Adactio
- Peter Paul Koch on Quirksmode
- Robert Nyman on Robert’s Talk
- Chris Heilmann on Wait Till I Come!
- Roger Johansson on 456 Berea Street
If you start from there with an open mind you’ll become a JavaScript megastar and a way better designer.
