Why Many Languages Eventually Learn to Speak JavaScript

Here’s a strange little fact about the web. For years, if you wanted code to run inside a browser, JavaScript was essentially the language you had to speak. So developers came up with a clever workaround: write in another language, then translate it into JavaScript before it reaches the browser. And even today, that trick powers a surprising amount of the web.

If that sounds like a workaround, it is. But it's also one of the most useful workarounds in modern software, and it's why you can write code in a language you actually enjoy and still ship something that runs perfectly fine in Chrome on someone's five-year-old Android phone in Lagos or Nairobi.

Wait, why does it all have to become JavaScript anyway?

Think of a browser like a very particular waiter at a restaurant who only speaks one language. You can order in whatever language you're most comfortable with, but eventually, someone has to translate that order into the one the waiter understands, or your food never arrives. For a long time, JavaScript was essentially the only language our browser ‘waiter’ understood. Today, WebAssembly gives it another option, but JavaScript remains the web’s default language.

So when developers wanted the safety of TypeScript, or the elegance of a language like Elm, or even just tomorrow's JavaScript features running in today's older browsers, they didn't wait for browsers to change. They built compilers, or as this specific flavor is usually called, transpilers, that quietly rewrite one language into another before it ever reaches a user's screen.

Transpiling isn't the same thing as compiling, even though people mix them up

A regular compiler takes your code and turns it into something low-level, machine code a computer's processor can run directly. A transpiler does something a little different. It takes your code and turns it into a different but still readable programming language, usually one that sits at roughly the same level of abstraction. Write TypeScript, get JavaScript out the other end. Write tomorrow's JavaScript syntax, get today's JavaScript out the other end, just older and more universally supported.

You've probably already used a transpiler without thinking about it that way. If you've ever written TypeScript, or used a modern JavaScript feature and watched it somehow still work in an older browser, a tool called Babel, or its faster modern cousin SWC, already did this exact job for you quietly in the background.

It's not just JavaScript's close relatives anymore

This is where it gets genuinely interesting, and where a lot of people's mental picture of "transpiling" is a few years out of date. It used to mean converting JavaScript-like languages into JavaScript. TypeScript into JavaScript. CoffeeScript into JavaScript, back when that was still a thing people used. Small, friendly translations between close cousins.

Today, entire ecosystems that have nothing to do with JavaScript compile down into it. Kotlin, the language a huge share of Android apps are written in, can compile straight to JavaScript through Kotlin/JS, letting teams share real business logic between their Android app and their website instead of writing the same thing twice. Dart, the language behind Flutter, can compile for the web too, including to JavaScript, and newer web builds can also make use of WebAssembly.

Somewhere in a university lab or a hobbyist's spare time, someone has probably tried compiling nearly every language you can name into JavaScript at least once. Most of those experiments never leave GitHub. A handful of them turned into tools real companies depend on daily.

Why would anyone bother doing this?

A few genuinely good reasons keep this whole approach alive, instead of everyone just learning JavaScript and calling it a day.

The first is safety. JavaScript on its own doesn't check your types, meaning it won't stop you from accidentally treating a number like text until your app is already broken in front of a real user. TypeScript adds that checking layer, catches the mistake while you're still typing, then quietly disappears into plain JavaScript once your code ships. You get the safety net during development without asking browsers to change a single thing about how they work.

The second is reuse. A company with an existing Android app written in Kotlin doesn't want to rewrite years of tested, working logic just to also have a website. Compiling that same Kotlin code down to JavaScript means one team, one shared codebase, and far fewer bugs sneaking in from two separate implementations of the same feature quietly drifting apart over time.

The third is timing. Browsers move slowly and carefully on purpose, because breaking the web for billions of people is not a mistake anyone gets to make twice. Developers, understandably, don't want to wait years for browsers to catch up before using a language feature that already makes their life easier today. Transpiling lets you write using tomorrow's tools while still shipping something that works perfectly fine in the browsers people are actually using right now.

You're not really choosing between "the real language" and "the browser version." You're choosing which language you'd rather think in, and letting a tool handle the translation nobody wants to do by hand.

The trade-offs nobody mentions in the getting-started tutorial

None of this comes completely free, and it's worth knowing the costs going in rather than discovering them the hard way at 11 pm during a deploy.

Debugging gets one layer more complicated. When something breaks, you're often looking at generated JavaScript that doesn't look anything like the code you actually wrote, which is exactly why a technology called source maps exists, quietly mapping the compiled code back to your original file and line number so your browser's dev tools can still point you to the right place.

Bundle size is the other real cost. Compiling an entire language runtime into the browser, the way Pyodide does for Python, isn't free. It can mean users downloading several extra megabytes just so Python can run at all, which matters a lot more on a shaky mobile data connection than it does on fast fibre in an office building. This is exactly the kind of tradeoff worth testing on a real, throttled connection before you ship it, not just on your own fast office wifi.

And build complexity creeps in quietly. Every transpiler you add is one more tool in your build pipeline that can break, need updating, or behave differently across your team's machines. It's manageable; developers deal with this successfully every single day, but it's not nothing, and pretending otherwise is how small projects end up with build processes nobody on the team fully understands anymore.

Where this is actually heading

WebAssembly, often shortened to Wasm, is starting to take over some of the jobs transpiling used to handle alone, especially for languages like Rust or C++ that need real, close-to-the-metal performance in the browser. But WebAssembly isn't a replacement for everything transpiling does. It's a different tool suited to a different kind of problem, and honestly, the two now increasingly work alongside each other rather than competing for the same job.

What probably won't change anytime soon is JavaScript's special place on the web. It's still the web's default programming language, supported everywhere without developers needing a separate compilation target. And as long as that remains true, developers will keep finding clever ways to write in the languages that suit them best, whether that means translating their code to JavaScript or, increasingly, compiling it to WebAssembly.