Why Javascript is a Joy

I’m probably a bit biased – being a front-end web developer for a few years will do that – but I really enjoy writing Javascript. I’ve recently retreated from pure coding the last few months, but I got an opportunity this past week to jump back into some tasks, and it has reminded me how fun it is to dive into our{{1}} front-end codebase.
Yes, Javascript can be surprisingly elegant yet completely infuriating, and all on the same line of code; for a long time, it remained the joke of the programming community, the deranged cousin that outuglied even the likes of PHP and Perl. Nowadays, JS is the language in the spotlight, and having its strengths exposed to increasingly more developers make me happy to have stuck with the language, warts and pus and all. Here’s my attempt to collate exactly why I like working with Javascript.

Speed

Google’s V8 Javascript engine has enabled faster code execution (in both our web browsers and our servers), and that has paved the way for additional complexity and structure. We now send hundreds of kb’s of minified Javascript to the client, and we expect all of it to run smoothly. Along with hardware-accelerated animations,  HTML5 mobile apps are quickly catching up to their native counterparts in terms of look-and-feel.
Moreover, JS is really fast to write and test. Write – save – refresh{{2}}; it’s an absurdly fast dev cycle that lets me iterate on questionable portions of the code much faster than any environment I’ve worked in. With the readily available (and quickly instantiated) webkit console and debugger, it’s a pretty powerful and productive coding environment{{3}}. I’m also warming up to Jasmine for unit testing; it has the right set of tools to deal with modern MVC objects, and hundreds of tests execute in a matter of seconds. Best yet, having the entire suite of tests run and complete on a whim enables better TDD practices.

Simplicity

Javascript, for everyday non-gotcha coding, is a pretty lightweight language. The list of reserved words is hardly intimidating, and there is a similarly limited set of types to worry about once you get past the unfortunate string-number auto-casting. JSON has become a preferred transfer format precisely from its simplicity, concision, and readability.
The web has deemed Javascript a part of its native tongue, and there are a ton of diverse tools available, most with minimal setup. My favorite pairing interview questions involve sitting the candidate in front of a computer with nothing more than a browser and a text editor; not only do we have the aforementioned browser console and debugger, but we also have access to APIs, libraries, and frameworks. We can tackle anything from storage systems to object modeling to data structures to user interfaces.
Plus, I don’t particularly like managing gem versions, especially as a prerequisite to running my dev instance.

Freedom

With simplicity comes Javascript’s greatest asset – the freedom to code in whatever way makes sense to you and your crazy band of fellow developers.
Maybe framework authors want to keep downloads small, or maybe they’re in on this shared philosophy of keeping things simple, but I honestly haven’t find that many popular Javascript libraries/frameworks that make their developers buy into their systems, the same way Rails and Django and CakePHP set up strict conventions for their respective frameworks{{4}}. The highly regarded ones (e.g., jQuery, Underscore.js, Backbone.js), in addition to being completely readable, maintain a lean codebase and actively limit their scope. They’re designed to do a few things well, and are happily interoperable.
A theme I have come across the frameworks I’ve used on both the client and server is that inevitably, I struggle with dealing with force-fed conventions which break on more interesting problems. I’m forced to go down a path of unfurling layers of abstraction, finding that one variable assignment that I undo back on the top of the software stack. Whether it’s patching middleware in Pylons, controlling DOM structure in GWT widgets, or tweaking the modalness of dialogs in Win32, they’re well-meaning to start but burdensome in the face of unconventional requirements.

Malleable

There is some truth to happiness in code deletion: it reduces complexity, fixes bugs, and shrinks the maintenance footprint.
So in a strange way, I’m happy that the messy Javascript I sometimes write tend to not last long. By nature, front-end code has a short shelf life: pages are redesigned, A/B tested and overhauled in short succession, and my painstakingly elegant carousel implementation may not have a place in the new design. The modular, drop-in nature of Javascript in the browser lets me refactor a widget out of existence without having to tease apart type hierarchies and de-metaprogram class functions. It’s especially easy when I have a few tests backing up the procedure.
Really, that’s all it takes. As easy to write as it is to unwrite, Javascript is a joy.
[[1]]That is, Square’s.[[1]]
[[2]]And if it’s completely static code – the rich Javascript app – I don’t even need a server.[[2]]
[[3]]Then again, I’m old school and use console.log way more than I should.[[3]]
[[4]]Sencha and Sproutcore are the only ones I can think of. Cappuccino shouldn’t count.[[4]]