You Don't Have to Choose Between New Syntax and Old Browsers

The last post promised this would be less of a blocker than it sounds. Here's the actual argument.

"I can't use that, I still have to support IE11." It's the most common reason developers give for staying away from new JavaScript syntax, and it sounds reasonable.

It's also based on a wrong assumption: that the code you write has to be the exact code that ships.

The Real Risk Isn't Using New Syntax Too Early

Plenty of developers treat old-browser support as a reason to stay years behind. Some go further than that. Strict mode landed in JavaScript back in 2009, over a decade before this course was recorded, and there are still production codebases that never turned it on.

That's the real risk: not adopting something too early, but staying so far behind that you stop tracking where the language is going at all. New syntax exists to help you say what your code means more clearly. Sitting a decade behind isn't caution, it's giving up that benefit entirely.

The goal isn't to grab every feature the moment it lands, either. It's staying aware enough of where the language is heading that you can use a new feature once it genuinely makes your code clearer, instead of finding out about it five years late.

How a Transpiler Closes the Gap

The tool that makes this possible is a transpiler, most commonly Babel. It reads code written in the newest JavaScript syntax and rewrites it into older syntax that an old engine can run.

Say you write this today:

An engine that doesn't support arrow functions or template literals can't run that directly. Babel converts it into something that engine understands, roughly:

You never write the second version by hand. You write the clearest syntax available, and the build step handles translating it backward. The gap between "what you write" and "what ships" is the transpiler's job, not yours.

How much of that gap you actually need depends entirely on your users. Support only the last couple of browser versions, and you'll rarely transpile anything, most new syntax is already there by the time you use it. Still supporting IE11, and the gap is bigger, but a transpiler closes it either way.

The Tooling Complaint Is Fair, the Alternative Is Worse

Setting up Babel and a bundler is a real cost. It's one more thing to configure, one more thing that can break, and it's fair to miss the days of writing a script tag and refreshing the page.

But avoiding new syntax over it gets the trade backwards. A build step is something you configure once and mostly forget. Code written in a style the rest of the language has moved past is something you, and everyone after you, reads forever, the same cost readable code is supposed to save you from in the first place.

That trade only gets better from here. The features this series covers, destructuring, generators, async/await, all reached the point where transpilers and modern engines both handle them well. There's rarely a good reason left to write the old, harder-to-read version by hand.

Next up, the first of those features: what template strings actually replace, and why string concatenation was worth retiring.