(This is part 2 of a series of posts on HTML5 from the point of view of a converted .NET developer)
JavaScript is hardly everybody’s favorite language. I’ve talked to numerous developer in the Microsoft-centric .NET developer universe (which was more or less my exclusive area of work from 2001 to 2010) and a lot of them found interestingly graphic ways to express their disdain for this language. Some of them were 100% clear that a shift of their company towards JavaScript would initiate their immediate departure from said organization. (If I’d draw a comic strip about this, I’d have to use my monthly allotment of symbol-characters within the first frame. It would look a lot like static line noise just after your modem’s carrier started to drop, if you know what I mean.)
But why is this language is so polarizing? Well, at first, it’s an old language. With a lot of baggage. Designed in a different world. But these are things you can work around … otherwise Visual Basic 6 wouldn’t have had that many vocal supporters when .NET was introduced in 2001/2002. And C++ would have none today.
JavaScript’s Issues
There are however two critical issues with JavaScript.
For one, JavaScript is largely paradigm-free. You can write procedural code, functional code and OO-code with it. But the latter comes with its own culprits: JavaScript is a prototypical-language, not a class based one. This basically means that objects inherit behavior from other objects, not from classes. But life would still be easy at this point … if it weren’t for the fact that most modern JavaScript code also heavily relies on closures. For someone living in the .NET space, the flexibility of closures in JavaScript is dramatic. (And if you live in the Microsoft space, you can in fact fare quite nicely without ever explicitly knowing what a closure is … so don’t mind if you don’t yet know how powerful they can be.)
The second - and maybe more important issue - is quite likely simply rooted in the history of the language: if you base your love or hate of JavaScript on your recollection of code written before, say, 2006, you’re missing out big time. The pre–2006-style of code largely outdated and no longer used. But it’s not that JavaScript has received some new and powerful features afterwards, instead it’s simply just that people started to write larger-scale software with JavaScript around that time. And this lead to the creation of frameworks like the Dojo Toolkit in 2004, Prototype in 2005 and jQuery in 2006.
These frameworks not only provided solutions to important issues at that time, but they also provided guidance to other JavaScript developers. The world started to shift from mainly-procedural onclick-handlers with hundreds of global variables towards sophisticated, encapsulated, extensible and reusable code. It really seems that this paradigm-free language was in dire need of some paradigms.
Learning to love It
I generally believe that there’s going to be a substantial amount of JavaScript in our future. And even if you decide that you don’t want to write the language, you should at least be able to read it.
If you’re - like I was in 2010 - returning back to this language, I’d like to recommend this one book, which has dramatically changed the way I think about JavaScript. I learned that basically everything I thought about JS was wrong … nothing more, nothing less.
JavaScript - The Good Parts by Douglas Crockford
But no matter if you plan to spend a lot of time with this language, or if you just want to know enough to get by, there’s one thing which you absolutely, positively have to understand to be able to read any current JavaScript code. It’s how this language deals with closures and how they are used to create private object members. Douglas Crockford has written about this in 2001, and in the meantime, the approach outlined in Private Members in JavaScript (and comparable ways of reaching the same goal) is one of the main ways how encapsulation is achieved in JavaScript.
Now, truth to be told, I’d actually recommend that you read the book if possible, because his writing and his way of explaining things is quite a bit better in the book compared to the old online-article. But the end-result remains the same: only after understanding how closures work in JavaScript will you be able to read the majority of today’s JavaScript code. It this is going to be vitally important for a .NET developer — because this is one of the two big differences (prototypes being the other) between your language of choice and JavaScript.
This single thing stood between me and my enjoyment of this language for a very, very long time.
Now after making the language work for you, it’s time to look at the various frameworks and libraries, which is going to be the focus of the next posts …
Comments