Engineering
If You Wish to Write JavaScript from Scratch, You Must First Create the Universe
A recipe for a modern JavaScript project
Imagine you’re a writer, and when your muse visits, you have to hunt down a large bird, pluck a feather, sharpen the quill, mix your ink, and so on (you get the point) before you can put your first word to paper.
Or you’re a painter, and whenever inspiration strikes, you have to stretch a new canvas before you can apply your first stroke.
This would be a terrible way to work. Yet — contrived examples aside — this is exactly how many JavaScript developers start new projects every day.
How did this happen?
Write Modern JavaScript… Now!
Have you heard the good news? JavaScript is a great language now! It’s got first-class support for modules, cleaner and more concise functions, multiple ways to avoid callback hell, and loads of new, can-live-without-’em-but-why-would-you language features that make writing JavaScript not just tolerable, but actually enjoyable. Now more than ever, JavaScript feels like a first-class programming language.
But there’s a catch: If you had to write a small piece of Good, Modern JavaScript right now, targeted at the browser, how would you do it?
In a recent conversation in Postlight Slack, Kevin Barrett sums up the problem I’m getting at:
I was looking at
terrainthe other day and realized that if I were to decide to write a single file of JavaScript to experiment like that repo does I wouldn’t know where to start. Is there a known/accepted baseline way to immediately start writing modern (the good syntax) JavaScript? Or do I have to wrangle a bunch of tooling every time before I start?
A Recipe for a Modern JavaScript Project
Seasoned JavaScript chefs include the following ingredients in nearly any modern JavaScript project:
- Support for ES2015 features (and beyond), more often than not transpiled via Babel, compiled via Webpack or maybe Rollup.
- Testing, with Jest as the testing framework du jour (oh and don’t forget, you need to make sure you also set up Jest to respect your Babel config).
- Linting, with ESLint. (You have your
.eslintrcready to go, right?)
If you wanted to cut it down to the bare minimum (not recommended), you can get rid of testing and linting. Now you’re left with setting up Babel and your build tool (let’s say Webpack). So you choose a Babel preset (stage 0 if you’re feeling lazy), add any plugins you might need (you’ll need to do a lot more of this if you didn’t choose stage 0), and set up your build tool.
This alone would take most seasoned developers the better part of an hour if they were starting from scratch; for people new to the ecosystem, the tooling step is intensely intimidating.
Now let’s say you only have five minutes and you just want to write some code.
Get You Some Boilerplate for Great JavaScript
When I asked a small group of my smart and talented colleagues at Postlight what they do when they want to write modern JavaScript right away, everyone recognized the problem, and their solutions varied by engineer, but Drew Bell’s answer more or less sums it up:
I have a base
package.jsonI copy paste around, but more often I use one of the base boilerplate thingies. I tend to trust other people on the internet instead of my own old man memory.
I’m 100% with Drew on this. If, for example, I want to start writing anything targeted at the browser, I’ll use create-react-app, a tool from Facebook that scaffolds boilerplate setup for a modern React app. I’ll use create-react-app even when I’m not planning to use React, because in a couple of minutes, I can start writing modern JavaScript that targets the browser without spending an hour sharpening my quill. (More than one Postlight engineer does the same.) If and when I need to change my configuration, my src folder shouldn’t have to change at all.
It’s sacrilege to some, but your JavaScript toolset should include boilerplates. Boilerplates are a huge productivity boon, especially given the current state of JavaScript. GitHub is full of them. Most of them aren’t sexy. Most don’t provide a fancy CLI for interactively rolling a new project. But they are effective. You clone a boilerplate repo, yarn/npm install, yarn/npm start, and you’re off to the races.
At Postlight, for example, we’re bullish about the serverless architecture. More specifically, we’ve had a lot of success using the Serverless framework alongside Amazon Web Services (in particular Lambda and API Gateway). So rather than reinvent the wheel every time we spin up a new serverless project, this starter serverless boilerplate lets any of our developers immediately start writing and deploying modern, serverless JavaScript functions.
I hear you, there in the back: But if your code relies on Webpack, you should know how it works. I get it. But here’s my counterpoint: I’ve written plenty of Webpack configs from scratch. Any time I’m not copying and pasting from a previous config I’ve written, it’s as though I’m learning Webpack again for the first time. Maybe I’m a bad programmer; or maybe Webpack isn’t my code, and when it’s necessary to change it, I’ll figure it out.
So What Do You Do?
When you’re looking to write Modern JavaScript now, what’s your approach? Do you start from scratch, every time? Do you roll your own boilerplates? Do you use someone else’s? Or do you roll your eyes at all this tooling nonsense?
