Writing Less JavaScript

The web platform is built on three pillars: HTML, CSS, and JavaScript. Of the three, the latter often gets an outsized share of attention. In part, this is because as the platform evolves, JavaScript is the place where we can fill in the gaps, at least until browser developers get there. That's why we ended up with so many front-end libraries, polyfills, and shims, to make our environment usable.

It's also because JavaScript is "traditional" programming, which is seen as more difficult than HTML and CSS. Of course, if you've ever tried to bring a complex visual layout to life, you know that that's hardly the case. Indeed, a central argument of this book is that smarter use of style and markup lets us write less JavaScript—always a good thing.

Why should we want to write less code? For one thing, fewer bugs and better performance, since the fastest and most correct JavaScript is the script you never run in the first place. For another, programming in a newsroom means working on deadline, and it's just faster to write less.

Still, while we should want to reduce the size of our codebases, we don't want to play code golf—clever-but-unmaintainable code is not the point. And we don't want to eliminate scripts entirely, since we're building interactive graphics. In the following chapters, we're going to try to strike a balance: write only as much JavaScript as we need to do, and leverage the platform itself to get the most out of what we do write.