Or: How I Learned to Stop Worrying and Love the module
Javascript, it would be fair to say, has taken a lot of flack over the years, and I would be lying if I said that yours truly hadn’t been a relatively prolific detractor pretty much since I first started using the language back in 2006. To me, javascript represented the “sloppy end” of web development.
Javascript was where my application was no longer allowed to be beautiful. Javascript was the “dumping ground” where the average code base ends up looking like the wild west after only a relatively short incubation time. Javascript is where lines upon lines of bespoke, nuanced code get added to hundreds of obscure, structureless script files, held together by dozens of “black box” libraries that some other sucker suffered to create.
Javascript was, by and large, something I tried to write as little of as possible. Nobody was more surprised than me to observe (albeit peripherally) the ascension in popularity of Node.js, with its promise of being able to write javascript “Everywhere”. Further confounded was I by the subsequent rise of technologies such as ElasticSearch and MongoDB, which promised a javascript-like syntax right back to your data layer. To me, this sounded like the kind of thing that belongs in one of the deeper, darker circles of hell, perhaps a place to condemn those developers who don’t write unit tests.
Had the whole world gone mad?
However I stand before you a changed man! I put it to you that javascript is not only “not shit” but that the javascript ecosystem is now, more than ever, one of the most vibrant and exciting ecosystems operating in the development sphere today.
So what changed my mind? To explain precisely where I used to stand, here is a quick history of javascript, and my relationship with it.
A brief history of javascript
Javascript was born in 1995 when Netscape, creators of the then-dominant “Navigator” browser (launched just one year earlier) had the idea of creating a “glue” language that would help web pages become more dynamic. The internet was still in its infancy at this stage but crazy concepts such as “shopping online” were starting to come to fruition (the first iteration of amazon.com would go live that very same year).
Internet explorer 2 (also launched in 1995) was the first of Microsoft’s browsers to support Javascript and within 5 years Microsoft had toppled netscape to make Internet Explorer 6 the worlds most popular browser. Two years after that, open source upstarts Mozilla launched the Firefox browser, which also shipped with Javascript, and made Internet Explorer into a laughing stock among the web-browsing community. That is, until google dethroned them just a few years later in 2008 with their Chrome browser, once again shipping with Javascript (by this point completely ubiquitous).
Rewind a bit: in 1997 a specification known as EcmaScript (ES) was created – this specification was actually based on Javascript (retroactively, therefore, javascript is an “implementation of the Ecmascript specification”). The Ecmascript specification would continue to exist but would largely just sit in the background doing nothing and remaining unknown to a large proportion of the development community. It wasn’t until 2015, with the advent of the 6th edition of ES, that significant changes were made to the syntax and a serious attempt was made to modernize the javascript language. The changes proved to be wildly popular with the developer community at large and these days transpilers such as babel have removed any concerns about browser compatibility that would previously have dogged any upgrades to the language.
And so a common theme emerges: that of a very fast moving landscape. This is the nature of the internet and javascript, good old dependable javascript, gets dragged along for the ride. In doing so, Javascript itself was infected with a touch of the same breakneck pace. There are always problems to solve with Javascript – by the time the developer community has solved one, two others have emerged!
Enter the module
One of the biggest problems I faced in the early days of my javascript dabblage (over a decade ago now!) was this: I want to structure my files such that they are all neat and tidy, like my server side code is, but this platform will not let me do it. There is so much cruft I have to write just to get simple operations to be nicely encapsulated – How do I share data between files? I know there’s loads of stuff I’m supposed to be doing to my JS code such as minifying and concatenating and whatnot, how do I do all of that?
The way I eventually got around sharing data between files was to put a god object in the global scope. The way I got around the minification issue? Well… I just didn’t.
And the reason I didn’t is that the internet didn’t really solve these problems until relatively recently. The concept of a small, reuseable “module” didn’t really become truly ubiquitous until the appearance of angular in 2009 and the dojo loader, and it didn’t leave those frameworks until 2011 when require.js brought Asynchronous Module Definition to the masses. Around the same time though, a competing module-definition specification (common.js, as used and popularized by node.js) emerged and thus, like busses, we had three solutions to the problem where once we had none.
As if having three solutions wasn’t enough, some bright spark then came up with UMD (universal module definition) as a way of unifying them – the concept being to create one module definition to rule them all. The reality though, is as follows:
“Does it look like the user is using AMD? Okay cool the you are an AMD module, unless they aren’t, in which case see if it looks like they’re using common.js. They not using that either? Fuck it then, put it in global scope”
That, ladies and gentlemen, is the best we have at time of writing 🙂
Package managers and Build tools
Bower – the “package manager for javascript”, was introduced only in 2012 and is already looking to be on the scrap heap – since the cool new thing is to allow your module to be used both server and client side, NPM is fast making bower obsolete. More of that classy Javascript dethroning.
Perhaps the most hostile dethroning of all though appears to be happening among build tools – Grunt appeared in 2013 and changed the face of building javascript. Tasks such as concatanating and minimizing javascript were now trivial, but also so were things like creating js docs and running tests – Grunt was enabling us all to be better Javascript developers.
Despite releasing v1.0 earlier this year and still being in active development, it was largely abandoned in favour of gulp in 2015 – with gulp’s reign to be very short lived as the wind appears to now blow in Webpack’s direction less than a year later.
Has all this made javascript better then?
The reason I started to look more heavily into Javascript was basically because it started to interest me. What was once a scrappy little scripting language I would go out of my way to avoid appeared to be going through something of a renaissance and like most developers, I wanted to see what the fuss was about.
And suddenly the real reason I still hated javascript in spite of the rest of the world became obvious – all of these innovations, all of the problems being solved as quick as they’re discovered, all of the tools and paradigms coming and then going… I just kinda missed them all! Working largely on monolith applications had shielded me from the Single-Page application revolution, and my general avoidance of writing javascript entirely had shielded me from build systems and package managers. The fact that all of these innovations came on so suddenly goes some way to explaining, if not excusing, how this was all able to pass me by.
The pace at which the javascript landscape is changing is to be utterly applauded – NPM, at time of writing, holds the world record for number of hosted packages (and growing by an average of 400 new packages a day – four times ahead of its closest competitor according to modulecounts.com).
This is where the ideas are thriving – and so it follows, this is the place to be.
Mikey Hogarth 