This post is about
import lib from 'awesome-lib';
Except that single, seemingly simple line, carries a lot of hidden work and understanding behind it. So here begins my complaint. But first here's an unimported bear…
SPONSORBuddy: The DevOps Automation Platform
Get the most powerful and easy-to-configure continuous integration and delivery platform.
So delicately simple
This simple statement of code is incredible powerful. By no means do I intend to undermine the years and years of work that has gone on and laid the groundwork to allow us to have an import statement in the browser.
Today, in all the modern browsers, we can use an
import statement on the web with no additional tooling. Dynamic imports aren't far behind either (an import that returns a promise - useful for lazy loading).
Right on the edge of the horizon are Import Maps which will bring support to the browser for "bare import specifiers" (currently available behind flags in Canary). Once import maps are stable feature of (at least†) the latest browsers, then imports have come to [a fuller] fruition.
† Why "at least" - what about cross browser support? I explain in the section on prototyping
Until then, in the browser we can do this:
import lib from './my-lib.js';
…but we can't do this:
import lib from 'your-lib';
Well, you can, but it requires a lot more specialist knowledge.
I really want to do that!
Importing modules brings a stability to development that historically browsers didn't have the pleasure of hosting.
Modules also offer code organisation which can (or "should") lead to better and more complete tests. Tests lead to stability and stability can be enjoyed by both the business and it's visitors.
There's also a matter of security: global scope provides another attack vector for potential bad actors that are included onto web sites - third party adverts are a potential entry point.
Thankfully the desire for a module system arrived years ago. My first encounters were with require.js. However, I always struggled with the (now relatively small) overhead required to make a compatible module. This was called AMD - here's a primer if you wish to go down memory lane.
Of course we now have Browserify, Rollup, Webpack and a slew of other tools that allow developers to benefit from modules. The crown jewel of tools is (IMHO) Babel.
Babel allowed us (and still does) to write tomorrow's code, today.
These tools are just the tip of the iceberg when it comes to tooling and workflow required to import, dare I say, synthetically for the web.
I digress, let's get back to today.
Bare import specifiers
This is what I use all the time in Node.js when I'm importing a module. Except I use the
const lib = require('your-lib');
Now it's a little unfair to compare
require from Node to
import for the web, and Myles Borins did an excellent break down of this at jsconf.eu 2018.
It's worth at least being mindful that there's a potentially complex system hidden underneath the software that's going to resolve exactly where
your-lib exists. For Node, it's a sequence of resolution logic. Node however uses a synchronous method to resolve and running modules, whereas the web doesn't have a synchronous loading method at all. The web is async.
As it is today, a bare import, using the
import statement, in a browser, isn't possible without a build tool doing some heavy lifting first.
Prototyping the web
I've come to realise in recent years that my strength in development is prototyping. It's something that I'm good at and enjoy doing. My recent work at CERN to rebuild the WorldWideWeb in 5 days is a great example of this.
The web and browser combined, are what make prototyping so incredibly accessible. Software, good, stable, secure software takes a long time to write. The browser allows for quick, hacky, cobble-ly code to be achieve in a quite impressively small amount of time.
For me to build the WorldWideWeb.app browser in a week, meant that I didn't have time to build out the perfect workflow. I needed something that allowed me to start producing usable interfaces as quickly as possible. I knew that I would need a helping hand from larger frameworks (like React in my case) and I chose to use Parcel.js for my bundling needs. Importantly, this allowed me to
import and dynamically import early on in the project and quickly focus on the real problems at hand.
I absolutely adore this part of my work: the fact that so little is required to start to play with code in the browser.
As such, I want to be able to play around in the browser with just a single file: an HTML file with a sprinkling of
<script> tags. I don't relish the thought of having the urge to play, and then being slamming back down to earth as I realise that to
import lib from 'your-lib' I must first decipher and roll out a way of importing. After which I usually encounter so other shiny distraction and have forgotten about my original intentions.
…ergggh, what was I trying to say?
If you're writing some documentation for your project, please give a little thought to how your reader is going to interpret the
import statement to start using the project.
New developers to the web have enough on their plate with the plethora of frameworks, testing utilities, linting tools, editor plugins, transpilation tools, transformation tools, transfiguration tools and all the other amazing, really amazing, choices in front of them. Tripping them up at the first line of the code seems a little unfair.
Until then, I'll probably keep actively (trying) to remove my build tools and probably continue to be Moany McMoan on Twitter.