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 our1 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.


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 – refresh2; 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 environment3. 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.


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.


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 frameworks4. 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.


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.

  2. And if it’s completely static code – the rich Javascript app – I don’t even need a server.

  3. Then again, I’m old school and use console.log way more than I should.

  4. Sencha and Sproutcore are the only ones I can think of. Cappuccino shouldn’t count.

Share this article
Shareable URL
Prev Post

Software Abroad

Next Post

Don’t Build for a Bubble

Comments 21
  1. “Anyway I know only one programming language worse than C and that is Javascript. […] I was convinced that we needed to build-in a programming language, but the developers, Tim first, were very much opposed. It had to remain completely declarative. Maybe, but the net result is that the programming-vacuum filled itself with the most horrible kluge in the history of computing: Javascript.”
    Robert Cailliau – co-developer of the www
    Just sayin’…

    1. Could well be, but when was that quote from? Javascript has been a very misunderstood language until the like of Crockford and Resig shown what is possible rather than the kludge that was thrown together before. And as more and more “hardcore” developers have turned to Javascript the quality of the code that has been written has drastically improved. Look at it this way, you can open up Visual Studio, add in a couple of aspx pages, throw in some control and text from the toolbox, use the page designer… or you can code it by hand. 

      1.  For being a knowitall, you don’t seem to know that s-expressions only run once without the global flag.

    1. What would you consider a “higher power language” for web development that I’m missing? Coffeescript? GWT? Neither let you do things like http://square.github.com/tesseract/.

  2. Totally Agree!  : )  Those that don’t know… don’t know.  Call them JS: joy – denyers. Times are changing folks. Get on board.

  3. I have a toy test that, I guess, mostly measures object creation and method calling overhead. The results in millions of iterations may be interesting though:
    Java – 7.7
    C# – 7.0
    C++ – 2.7
    JS Opera – 0.57
    JS Chrome – 0.50
    JS IE9 – 0.38
    Ruby – 0.15
    PHP – 0.10
    Python3 – 0.07
    Looks like JS is not a toy. More so if Windows 8 is not a toy.

    1. You need to provide those tests.  This type of assertion flies in the face of my experience.  It seems to me there is NO way Javascript is > 10x faster than Java/C# and 5x faster than C++.  Think about it for a moment.  The Javascript engines (any of them) are developed using C/C++.  According to these results, the creators of the JavaScript engine have code running faster than the the original compiler.  Come on.  Be an evangelist but be be credible.

Leave a Reply

Your email address will not be published. Required fields are marked *

Read next