Or: How I Learned to Stop Worrying and Love the module
Had the whole world gone mad?
Enter the module
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
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.
This is where the ideas are thriving – and so it follows, this is the place to be.