JavaScript, oh JavaScript. You mistreated, capable language, forever doomed to nail annoying flying clocks to people’s cursors. That was the story, say, four years ago, anyway. JavaScript is in the middle of a renaissance now. It’s being used for useful things, like autocompletion on text fields, instead of the perpetual avian watchfaces of yesteryear, and while effects are still aplenty, this time many of them are actually quite useful. Still…
The big problem with JavaScript is that it’s a simple language at a low level, attached to HTML - probably the only non-Excel technology that’s even remotely “programming” that the man on the street would be able to tell you things about. Non-programmers write JavaScript, in droves, and the outcome is just not pretty.
Why am I being such an elitist about this? Am I not all about wanting technology to enable people to do cool things? Of course. The strongest trend on the Web has been one that’s been persistent ever since its conception, and one where a lot of momentum is going - letting everyone have a web site with relative ease. Aside from pages with cat pictures and animated horizontal rulers with Calvin and Hobbes, this also spawns a lot of writing with a lot of great ideas and unique perspectives. I am very impressed by this, and I am in no way opposed to this. But this isn’t about content, it is about code.
Non-programmers was a word picked very carefully. Probably the vast majority of the smartest people in the world are not programmers. This is not about being smart. Programmers are able to visualize how to break down a problem, how to solve it in the least steps in code, how to reduce repetition, how to thoroughly test edge cases, how to ensure compatibility, how to make the code robust. With very few exceptions, you either have this skill or you don’t, and so when people that are not actually programmers write code, chances are the outcome is functionally ugly and not well thought-out.
JavaScript’s position as a language so closely joined with HTML in today’s web browsers magnify this effect. When you search on Google for JavaScript, there is a very big chance you’ll be getting code snippets. It is hard to actually learn the language itself without, figurative scythe in hand, fighting through the jungle of snippets. This all piles up.
And yet, the ‘real’ programmers amongst us still overuse JavaScript from time to time. Beyond just getting the code right, using JavaScript properly - and I define “properly” as “in a way that actually enhances the site it is on substantially” - requires extreme vigilance and restraint. Using every component in the whole HTML-based hodgepodge correctly and to their maximum potential is nothing less than a form of art.
Let me share an example.
Starting a few months back, the online Apple Store started a new profiling effort. Many product pages now look and work substantially different. Put simply, they were able to fit more content into less screen real-estate. How did they do this? Small tabs everywhere, and JavaScript powering them. There are sub-sections of product info that (if you have JavaScript enabled) load without refreshing the page (by sending JSON), which is important on a store product page, because you don’t want to drag the customer away from the Buy button and you don’t want to waste more bandwidth than you have to. You can flip between one ‘tab’ of product info to another on the greater scale, and the philosophy trickles down to showing tech comparison tables in abbreviated or full form, all the way down to being able to view Mac and PC system requirements in tabs (this in particular is not remotely stored), saving space and cleaning up the entire page.
Why I’m bringing up this example is not because I’m impressed by the ingenuity of it (but rest assured that I am), no - I’m bringing it up because of another reason. You see, I’m currently reimplementing all of my partially outdated software site. I am using a lot of JavaScript to add small useful touches, like a product popup menu hidden away in a corner to facilitate easily getting to other products. Yesterday, I implemented a very close analogue to the Apple Store’s tab loading. It took five hours and I ended up throwing it away. Why did I throw it away?
My solution required loading the entire page in a hidden iframe in order to cherry-pick the correct elements to bring over. Even if it had turned out not to be buggy or unreliable in some cases, I realized that I was not saving bandwidth, and that I had no actual reason to not reload the whole page. I decided to just let links be links and I saved some valuable space in my script library, which in the long haul also means less to maintain, since every line of code is going to be a liability.
Sometimes, the really good solution isn’t really good for you. It’s all about being able to recognize what you gain from having that particular solution.
As long as I’m talking about this, I want to highlight another ground rule that I have in rebuilding the site: unless something lives and dies by JavaScript - and some legitimate applications do, like Google Maps - make it unobtrusive.
Being unobtrusive is an idea championed by many and under an array of other names (like Progressive enhancement and, vice-versa, graceful degradation), but it’s powerful nonetheless. The gist is that if someone with JavaScript disabled goes to your site, the content should just work, and if someone with JavaScript enabled goes to your site, the extra functionality should spring to life, and ideally, the HTML sent over the wire shouldn’t be much different.
Unobtrusiveness appeals in many ways. Less to maintain, better code separation and of course, being indistinguishable from magic. Getting the thinking nailed down can be hard if you’re used to getting at your HTML somewhat more directly, but it is definitely worth it. I have a “flippable” (expandable/collapsible) container element implemented by simply specifying three fields of extra metadata in the HTML (two ids and one class), and the screenshot gallery is almost completely set up by unobtrusive parts, being, simply, a list of links to the full screenshots in the source.
If you’re still writing “monolithic” sites - sites where the HTML basically requires being transformed into something else to be useful, or sites where the JavaScript generates other essential parts - I think you should check out Unobtrusive JavaScript. Hopefully, you’ll be thanking me.