We will talk about the launch of HTML5 Boilerplate, the transition to automated build systems, and the moments JavaScript went from a despised browser toy to an enterprise-grade discipline.

Before you can fully appreciate why we spent so much energy building those tools, you have to understand the hostile operating environment we were trying to escape.

If you entered front-end engineering in the last decade, you grew up believing browsers are cooperative runtimes. You think a rendering engine is broken if a CSS flexbox rule behaves unexpectedly on mobile Safari.

Let me take you back to an era when the web platform was pure trench warfare.

1. Table Layouts and the Load-Bearing Spacer GIF

Before CSS layouts stabilized, we did not align elements with math or anything approaching an elegant solution. We built layouts through structural abuse. If a client needed a header, a navigation sidebar, and a three-column content area, that meant nesting <table> tags seven layers deep.

To prevent empty table cells from collapsing, every commercial website on earth carried an invisible architectural wedge: the transparent one-pixel GIF (spacer.gif). You set its width and height explicitly in HTML attributes to physically pry open cells like a car jack. Miss one closing tag, and the entire page shattered into disconnected tiles.

2. DHTML and the ActiveX Precursor to AJAX

In the late nineties and early 2000s, “Dynamic HTML” was the buzzword. In practice, DHTML was just marketing speak for Netscape and Microsoft waging open warfare inside your script files.

Netscape 4 gave us document.layers. Internet Explorer gave us document.all. If you wanted an element to move across the screen, you sniffed the user-agent string and maintained two parallel codebases in the same file.

Asynchronous data loading was even wilder. Back in August 2008, I wrote an article titled “Some Internet Explorer Innovations You Probably Forgot About While Waiting for IE6 to Die.” It hit the front page of Digg(? Slashdot? One of those.) My argument was straightforward: despite everything IE got wrong, Microsoft effectively invented AJAX.

Before fetch() or standardized XMLHttpRequest, you did not invoke a native browser API. In Internet Explorer, you initialized an actual Windows COM component: new ActiveXObject("Microsoft.XMLHTTP"). You had to wake up the underlying Windows operating system just to update a fragment of text without triggering a full page reload.

3. The Mark of the Web

Local development during the Windows XP Service Pack 2 era came with its own brand of security theater. If you opened a local HTML file directly from your hard drive that contained any JavaScript, Internet Explorer threw an aggressive yellow warning banner across the viewport and froze script execution.

The official Microsoft workaround was a magic comment pasted at the very top of your HTML:

<!-- saved from url=(0014)about:internet -->

The 14 represented the exact character count of about:internet. If your character count was off by one, the parser disregarded the directive and your local scripts remained locked down.

4. The Occult Arts: hasLayout, zoom: 1, and DirectX Filters

Once CSS finally took over layout, Internet Explorer 6 introduced developers to hasLayout. It was an undocumented internal engine flag. If an element lacked layout, margins doubled on floats, background colors vanished, and containers refused to contain their children.

To fix it, we resorted to superstition. You injected zoom: 1 or height: 1% into your stylesheets. The properties had no logical business being there, but they tricked Trident into setting that internal flag to true.

Transparent PNGs were worse. IE6 rendered 24-bit alpha channels as solid matte-gray or baby-blue blocks. In a 2006 tutorial I published on cross-browser PNG transparency, the only viable solution was running proprietary Microsoft DirectX filters:

filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png', sizingMethod='crop');

It destroyed scrolling performance, broke hyperlink click targets, and required hasLayout to be toggled on just to render the graphic.

Why We Built What We Built

We did not invent modern front-end tooling because we were bored and wanted complex build pipelines. We built automated builds, linting, reset sheets, and boilerplates because we spent our twenties writing duct tape around runtimes that actively fought us.

The next time your build step throws a type warning or a CSS grid gap requires a minor fallback, take a breath. It beats debugging spacer.gif and toggling zoom: 1 at 2:00 AM.

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.

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.

A couple of weeks ago, I talked about the “Happy Path Trap”—how LLMs create massive Day 1 velocity while burying teams in silent Day 2 architectural debt.

During that discussion, I pitched an idea: What if we required an Assumptions & Constraints Manifest (ACM) in every AI-assisted PR to make hidden trade-offs visible?

Since I’m not one to wait around for someone else to build tooling I want to use, I spent the last few days building it out.

Today, I’m open-sourcing ACM v1.1—a formal spec and developer toolkit designed to audit architectural boundaries, not just syntax.

What’s in the toolkit:
Typed Contracts & Proof Obligations: Requires the PR to explicitly state guarantees around concurrency, idempotency, and scaling—citing exact line numbers and locking mechanisms.

Automated Generation: Drop-in .cursorrules and PR templates that prompt Cursor, Claude, and Copilot to generate manifests automatically during code creation.

CI/CD Linter: An open-source CLI linter (@roblarsen/acm-cli) and GitHub Action to validate manifests and gate PRs automatically in your pipeline.

Instead of spending 45 minutes playing digital archaeology on AI-generated diffs, reviewers can audit explicit boundaries in 30 seconds.

Get Started
GitHub: github.com/roblarsen/ACM

CLI: npx @roblarsen/acm-cli

• CSS Weaponized at Black Hat 2026: Security researcher Gareth Heyes dropped a research paper showing how CSS alone can break out of webmail sanitizers. Without a single line of JavaScript, malicious stylesheets in Gmail and Outlook were manipulated to spoof UI elements, capture keystrokes, and steal tokens. Stripping <script> tags isn’t cutting it anymore, apparently.
• The 2026 State of CSS Results Are In: The survey numbers show :has() leading as the most used newer feature, while Anchor Positioning holds the crown as the “favorite feature we wish had better browser support.” On the workflow front, 80% of developers report using AI for less than half of their CSS work. It turns out layout still needs humans!