f you've read the Twitters or checked out a JavaScript conference lineup lately — or, goodness help you, if you've reviewed a batch of conference proposals — you might think JavaScript these days is all about React and Flux and Redux and immutably isomorphic Babel-ified ES6, with maybe some web audio, offline, WebGL, VR, SVG, and an npm script or twelve thrown in for good measure. (I mean, gulp talks are sooooo 2014, amirite?) There's so much to learn about JavaScript that there are whole Medium posts about how there's so much to learn about JavaScript, and whole conferences to remind you how much you don't know.
Here's the thing: maybe you're lucky enough to live in this magical world where everything you build is shiny and new, but there are an awful lot of people working on client-side apps that came into being back when yayQuery was a thing and Backbone wasn't. They're building software that serves hundreds of millions of actual users, software that makes actual money, software whose underlying architecture is such that there's rarely such a thing as a “small change,” even as the demand for new features never subsides.
If you're one of these developers and you're starting to feel like modern JavaScript has left you behind, this talk is for you. I'll share the story of how I started a new job this year by paying a visit to JavaScript circa 2009, back when Ryan Dahl was getting ready to announce Node and Facebook was still four years away from being mocked for the apparent heresy of JSX. I'll explain how I modernized and best-practice-ified a project that didn't even have a package.json, smoothing the development process, eliminating common sources of bugs, paving the way for bigger improvements, and never once uttering the words “we oughta just start from scratch.”