If you spend your time in open-source mailing lists or arguing about AST transformations on social media, the recent push toward “erasable syntax” makes total sense.

I’ve been a proponent of TypeScript for a long time. In the early days, whenever someone brought up enum, for example, I remember having conversations along the lines of: “Oh, enum? That’s not real. That gets magically transformed into real JavaScript behind your back.”

And then I’d get a sparkle in wondering what IIFE monstrosity the compiler invented just to make it work. (I have to shout out Ben Alman, who was right here in our ridiculous Boston front-end scene when he popularized the term “IIFE” back in 2010. Little did Ben know the TypeScript compiler would end up weaponizing his naming contribution to haunt us sixteen years later.)

Back then, we loved pulling back the curtain. Do people even know what a polyfill is anymore? I have my doubts.

The thing is, most developers writing code for a living don’t live in that world.

“AST what?”

In the enterprise trenches, where teams were dragged out of desktop software and backend services into the chaotic swamp of modern web development, TypeScript wasn’t viewed as a lightweight annotation layer. It was viewed as a sanctuary.

Anders Hejlsberg designed C#, and then he designed TypeScript. To millions of backend engineers, TypeScript felt like fruit from the very same design tree. The mental model was simple: TypeScript was the bigger circle in the Venn diagram—the “typed superset” Microsoft explicitly sold us. You wrote enum, you wrote namespace, you wrote constructor parameter properties, and you trusted the compiler magic to handle the messy JavaScript plumbing underneath.

And for a decade, that compact worked fine. The build toolchain absorbed the weirdness, emitted runtime IIFEs, and everyone went about their day.

Then the enterprise joined the chorus asking for the holy grail: “Can Node please just run TypeScript natively?”

We got what we asked for. Node will execute your .ts files. But it does so with a massive asterisk that is going to bewilder anyone who learned TypeScript as “C# for the browser”: Node only strips types. It does not compile your bespoke runtime features.

The moment you run a raw TypeScript file in Node without a build step, that comfortable superset abstraction collapses. You have an enum sitting in an enterprise shared-utility file? Crash. A clever namespace? Crash.

Nobody in a corporate sprint planning meeting thought about the distinction between type-stripping and transpilation. They just assumed native TypeScript meant the engine would run their TypeScript code. Period.

Which brings us to erasableSyntaxOnly: true.

JSON

{
  "compilerOptions": {
    "erasableSyntaxOnly": true
  }
}

This flag is essentially the antidote to a decade of superset marketing. It forces the compiler to yell at you the second you write syntax that can’t be deleted with an eraser. Try to write an enum? It breaks in your editor before it can blow up your server.

It is a fascinating full-circle moment. For ten years, teams embraced TypeScript precisely because it felt like a richer, more familiar programming language than JavaScript. Now, if we want the dream of zero-build native execution, we have to teach those same teams that the extra features they loved were actually technical debt in disguise.

Fun times.