When you spin up a greenfield project on a Tuesday afternoon, a build step feels like a completely reasonable trade-off.

You install a bundler, configure a transpiler, sprinkle in a few TypeScript-specific conveniences, and marvel at the developer ergonomics. Having the compiler quietly invent runtime JavaScript out of thin air to support an enum, a runtime namespace, or constructor parameter properties feels downright luxurious. You get the strict typing of an enterprise language, the compiler sweeps the sawdust under the rug, and your local watch task hums along in 200 milliseconds.

Then… you get to enterprise scale. 🤣

Suddenly, it isn’t one developer tinkering on a tidy side-project. It’s four hundred engineers distributed across eight time zones committing to a multi-gigabyte monorepo.

That “harmless” build step isn’t a frictionless 200ms background blip anymore. It’s an eight-minute CI pipeline bottleneck.

At enterprise scale, the build step stops being a convenience and starts being a multi-million-dollar operational tax. Every second added to a build is multiplied by every developer, every pull request, every CI job, and every environment.

Which is why the recent discussion of native type-stripping and flags like erasableSyntaxOnly: true isn’t an academic purist argument. It is pure, ruthless pragmatism.

When Node can simply load a .ts file, delete the type annotations and execute standard JavaScript immediately your local feedback loop approaches zero. But to get that speed, you have to give up the runtime compiler magic that makes the “superset” features of TypeScript work.

The biggest beneficiary of this shift has been the humble object literal. If you haven’t made the shift yet, Axel Rauschmayer wrote a fantastic, definitive breakdown of replacing TypeScript enums with as const object literals. By freezing a plain JavaScript object and deriving your union types via keyof typeof, you get all the autocomplete, refactoring safety, and strict checking of an enum—except it’s just raw, native ECMAScript that runs anywhere without a compiler generating IIFEs behind your back.

The Inflection Point for ECMAScript

This shift does more than just rescue CI budgets; it marks a genuine inflection point for the ECMAScript specification itself.

For the better part of a decade, TypeScript was the web’s de facto R&D lab. The TC39 committee could watch Microsoft test language features in the wild to see what resonated with developers. But the lesson of the erasable syntax movement is forcing a deeper question: what was TypeScript doing that the ECMAScript spec itself should have absorbed?

We already saw the answer with classes, optional chaining, and nullish coalescing—features proven in TypeScript before landing in the formal JavaScript standard. The next frontier is the Type Annotations proposal, which aims to formally reserve type syntax in the ECMAScript grammar itself so browsers and runtimes can treat types as ignored comments by default.

If ECMAScript formally standardizes native type ignore spaces, the concept of a mandatory transpile-to-JS build step for day-to-day web development begins to evaporate entirely.

The convenience of language extensions was never an illusion. They helped bring static typing to an entire generation of JavaScript developers. But as our systems scaled from side projects to platforms, every non-erasable feature acquired a cost. The future increasingly looks like a world where types remain, build steps shrink, and the JavaScript that ships is little more than the JavaScript we wrote in the first place.