Why JavaScript Never Stops Changing

The last post argued that code exists to communicate with people, not the computer. Here's where that idea runs into its biggest test: a language that changes constantly.

Every few months there's a new blog post about a feature you've never seen. It's tempting to think you're falling behind.

You're not. This pace isn't a personal gap. JavaScript tried the two alternatives already, and both were worse.

The Decade Nothing Happened

From 1999 to 2009, JavaScript barely changed. That's the gap between the ES3 and ES5 specs, ten years with almost nothing new.

The web didn't stand still either, it just froze in a worse way. Internet Explorer 6 shipped and then went unpatched for over five years. Developers who wanted progress built their own browsers instead, which is why Firefox and Chrome exist.

Both were stuck for the same reason: the people in charge of JavaScript couldn't agree. A spec called ES4 split into rival camps that never made peace, so everyone just walked away.

The Fix That Took Six More Years

In 2009, the committee came back with one rule: there is only one JavaScript. No feature ships unless every browser agrees to build it the same way. No more IE running its own private version.

That felt like the fix. It was only step one.

2010 passed. Then 2011, 2012, 2013. From the outside it looked like another stall. What was really happening: the same old arguments, being settled one feature at a time.

That work landed in 2015, six years after the agreement and sixteen years after the last real update. It shipped with around 300 new features and changes, modules, classes, arrow functions, and dozens of smaller ones, all at once.

That's the release people call "the day JavaScript changed overnight." It didn't change overnight. It changed over sixteen years and then arrived on one day.

Where "JavaScript Fatigue" Comes From

A change that size, after that long a wait, is exactly what makes people feel left behind. Every blog post afterward was full of syntax nobody recognized.

That's where the term JavaScript fatigue comes from. Some people even argued the language should pause new features for a while and let everyone catch up.

The committee had just lived through both extremes, ten years of silence and then one giant dump. Neither one was acceptable again.

The Process That Replaced Both Extremes

So instead of big, occasional versions, JavaScript switched to one small, named release every year. The naming changed too: not "ES7," but ES2016, then ES2017, ES2018, and ES2019.

Whether a feature makes that year's release depends on the TC39 process, five stages every proposal moves through on its own timeline.

Only proposals at stage 4 by the year's early committee meeting make that year's release. Everything else just rides on to next year, no penalty.

That's why a tiny fix, like ES2019's change to how JSON.stringify handles certain characters, and a big one, like flat-mapping arrays, can ship in the same release. Each proposal moves at its own speed, not the speed of the slowest thing around it.

Why Nothing Ever Gets Removed

One rule explains why this process is so careful: once a feature ships, it can't be taken back.

Pull a feature a real website depends on, and that site breaks for real people. It's the same reason you lock your build environment to an exact version instead of letting it drift. Changing something people already rely on is the expensive mistake, not the careful one.

That's why a proposal has to be documented, tested, and built by more than one engine before it reaches stage 4. Shipping something half-finished isn't a small mistake here, it's a permanent one.

So When Does It Stop?

It doesn't. A language that pauses to let everyone catch up doesn't stay still, it gets replaced. WebAssembly already lets people skip JavaScript and ship Go or Rust straight to the browser.

What you can count on instead is the pace itself: one steady release a year, mostly small, occasionally big, each piece finished before it ships. You never re-check that 1 + 1 = 2 before using it, and you don't need to re-check a stage-4 feature either. It already survived the hard argument before it ever reached you.

The features this series covers, template literals, destructuring, new array methods, iterators, regex upgrades, async/await, all shipped between 2015 and 2019. Nearly every one exists for the same reason: to let you say what you want instead of spelling out how to get it.