You've likely noticed by now that JavaScript evolves fast. Every year, the TC39 committee drops new features that make our lives easier—things like optional chaining, nullish coalescing, or async/await. But here is the reality of the industry: you don't control the browser your user is using. While you might be on the latest version of Chrome, some poor soul is accessing your app on an outdated corporate laptop or a three-year-old mobile browser that has no idea what a ?. operator is.

The manual slog of "safe" code

In the early days, or if you're taking a very conservative approach, the way to handle browser compatibility was to simply not use new features. I remember spending far too much time writing "defensive" code just to avoid a crash. If I wanted to get a user's zip code from a deeply nested API response, I couldn't just grab it. I had to write this:

const zip = (user && user.profile && user.profile.address) ? user.profile.address.zip : 'Unknown';

It’s repetitive, it’s visually noisy, and it’s incredibly easy to miss one check in the chain, which leads to the dreaded Cannot read property 'address' of undefined. This is the "naive" way of ensuring compatibility—sacrificing developer experience and code readability to ensure the code doesn't explode on an old browser.

The risk of shipping raw modern JS

The opposite extreme is writing clean, modern JavaScript and shipping it exactly as is. With modern syntax, that zip code example becomes a one-liner:

const zip = user?.profile?.address?.zip ?? 'Unknown';

I love writing this. It's concise and expresses the intent perfectly. However, if you ship this raw file to a browser that doesn't support optional chaining, the browser won't just "skip" that line. It will encounter a character it doesn't recognize (the ? in that specific context), throw a SyntaxError, and stop executing your entire script. Your whole app goes dark because of one elegant line of code. Now we're stuck in a trade-off: do we write ugly, safe code, or beautiful, risky code?

Bridging the gap with transpilation

This is where Babel comes in. Babel isn't a compiler in the traditional sense (like turning C++ into machine code); it's a transpiler. It takes source code written in one version of JavaScript and transforms it into another version of JavaScript.

Instead of choosing between readability and compatibility, you write the modern version, and Babel automatically rewrites it into the "safe" version before it ever reaches the user. When Babel sees user?.profile, it essentially rewrites it back into those clumsy if checks or ternary operators we saw earlier. You get the mental clarity of modern JS during development, and the user gets the boring, stable ES5 code that runs everywhere.

The cost here is a build step. You can no longer just link a .js file in your HTML and call it a day; you need a process (usually managed by Webpack, Vite, or a dedicated Babel CLI) to run your code through the transpiler. To me, this is a negligible price to pay. I'd much rather spend five seconds configuring a build tool than spend five hours manually writing null checks for every single object in my codebase.

📋 Practical Task

Exercise: Converting Modern Syntax to ES5

Imagine you are debugging a legacy project where the build pipeline is broken, and you need to manually "transpile" a piece of modern code to ensure it runs on an ancient browser.

Below is a snippet of modern JavaScript using Template Literals, Destructuring, and Arrow Functions. Rewrite this function into standard ES5 JavaScript so that it is compatible with browsers that do not support ES6.

const greetUser = ({ name, city }) => {
  return `Hello, ${name}! Welcome to ${city}.`;
};

Requirements:

• Replace the arrow function with a standard function declaration.
• Remove the object destructuring in the parameters.
• Replace the template literal with traditional string concatenation.