After spending an hour debugging why wide ANSI terminal art was breaking our page layout on a retro browser interface, I called it "classic web dev."

The response: "This is literally why I'm a systems architect and not a frontend designer, LOL"

And honestly? Fair. We had just debugged "make wide content stay inside a box" - supposedly the most basic thing in web development. But the journey involved:

1. "Elements are disappearing!" (they weren't, they were scrolled off-screen)
2. "Is it CSS corruption?" (no, it was horizontal layout explosion)
3. "Try overflow-x!" (CSS3, won't work on IE5)
4. "Try max-width!" (breaks padding calculations due to box model)
5. "Try table-layout: fixed!" (not sufficient alone)
6. "Try max-width: 0 on cells!" (breaks the entire header)
7. "Add a specific class!" (finally works)
8. "Do we even need overflow-x?" (nope, simpler without it)

All of this just to make a rectangle stay inside another rectangle.

Meanwhile, in systems architecture: "Distributed consensus across 10,000 nodes? Yeah, I can reason about that." But CSS? "Why won't this box behave??"

Frontend is chaos held together by duct tape and the tears of developers who just wanted things to line up.

Then came the kicker: "Insert disgruntled comment here about nodejs bleeding frontend into backend and progressive enhancement kicking all ya'lls ass"

The irony is rich. The web development community spent years touting progressive enhancement as a best practice:

The Promise: "Build for the baseline, enhance for modern browsers!"

The Reality: Builds entire app in React with 47 npm packages, requires ES2020 and WebAssembly, breaks on anything older than Chrome 90

We're not doing progressive enhancement. We're doing progressive hope - starting with modern browsers and praying it degrades gracefully to... well, not IE5, that's for sure.

And Node.js bleeding frontend chaos into the backend? It gave backend developers a whole new set of problems:

• Webpack configs for server code
• node_modules being 500MB for a "hello world" app
• "This package requires ESM but that one needs CommonJS"
• NPM supply chain attacks
• Dependency hell 15 layers deep
• Just to leftPad('hello', 10) on the server instead of writing 3 lines of code

Meanwhile, this project runs a Go binary that:

• Compiles to a single static executable
• Serves HTML 4.01 Strict
• Works on IE5 from a G3 Mac running at 266MHz
• Also works on modern browsers
• Has zero npm dependencies (because there's no npm)

Frontend complexity is kicking everyone's ass, even when we actively try to avoid it.

The real story isn't just about technical choices. It's about a philosophical shift that happened in three distinct phases:

The Punchline:

We spent a decade:

1. Abandoning progressive enhancement
2. Building SPAs that broke accessibility, SEO, and performance
3. Creating frameworks to "solve" problems we ourselves created
4. Rebranding progressive enhancement as "modern best practices"
5. Acting like we invented something new

Meanwhile, this 1999-browser-compatible approach does all of this correctly by default:

• Server-side rendering (Go templates)
• Works without JavaScript (form submissions)
• Enhanced with JavaScript (XHR for modern browsers)
• Accessible (semantic HTML 4.01)
• Fast (minimal payload, no bundle)
• SEO-friendly (real HTML, not JS-rendered)
• Progressive (iframe callbacks for IE5, SSE for modern)

The architecture proves something important: Nothing about web technology required breaking backwards compatibility. We just stopped caring.

The Proof Points

The tech stack from 25 years ago is completely capable:

• HTML 4.01? Still perfectly functional
• CSS 2.1? Does everything you need for layout
• ES3 JavaScript? Totally capable of interactivity
• HTTP/1.1? Works fine
• Server-side rendering? Never stopped working

This project runs a 2025 AI API through a 1999 browser. The limiting factor is CSS box model quirks, not fundamental impossibility.

What changed wasn't capability, it was willingness:

• "Supporting IE is too hard" → so we stopped
• "Polyfills are annoying" → so we required modern JS
• "Progressive enhancement is extra work" → so we built SPA-only
• "Old browsers don't have XMLHttpRequest2" → so we broke them
• "Testing on old browsers takes time" → so we deprecated them

But none of that was necessary. It was a choice. We traded universal compatibility for developer convenience.

Here's where it gets interesting. Not only could we have maintained compatibility, but had we stuck to progressive enhancement principles, we could theoretically still support browsers as old as IE5 today.

Imagine a modern framework written with this mindset:

At every layer, it degrades gracefully. This project proves it's possible because it does exactly this:

• IE5 gets: server-rendered HTML + iframe callbacks
• Modern browsers get: same HTML + XHR + SSE streaming
• Both work. Same backend. Same HTML structure.

The counterarguments fall apart under scrutiny:

• "But modern apps need modern features!" → This AI chat works on IE5
• "But performance!" → A G3 Mac at 266MHz handles it fine
• "But developer experience!" → This was built, it wasn't impossible
• "But maintenance burden!" → This stack is simpler than most modern apps

Taking it even further: with a little inventiveness, you could have HTML 4.01 upgrade to newer HTML versions purely server-side. This goes beyond normal progressive enhancement into something more interesting.

We used to do this! Early 2000s had WAP vs desktop detection. Mobile sites served different HTML. Server-side browser sniffing was standard practice.

This goes beyond progressive enhancement - it's capability-aware rendering. Same backend logic, adaptive presentation layer. And CGI scripts could have done this in 1995. We just chose not to keep doing it.

This isn't just theory. Real companies scaled to massive success with this exact philosophy.

Early eBay (AuctionWeb, 1995-1997) ran on C/C++ CGI scripts on a single Linux box in Pierre Omidyar's house:

They scaled this to millions of dollars in transactions before having to rewrite. When they did rewrite (to Java/J2EE in the 2000s), it was arguably more complex and harder to maintain.

Compare to today:

• Modern startups: React + Node + MongoDB + Redis + Kafka + Kubernetes
• eBay 1996: C CGI + Apache + flat files
• Which one actually made money faster?

This is why Go feels right for this project. It's the closest spiritual successor to "compile a binary that you just run" turning into a webapp - short of actually doing it in C.

Compared to Node.js:

"First install node, then npm install, oh wait wrong node version, install nvm, now install dependencies, oh this package needs python2.7 and node-gyp, oh this package is deprecated, oh security vulnerabilities..."

Compared to Go:

go build → done.

Go gives you C's simplicity and speed but with:

• Memory safety (mostly)
• Standard library that doesn't suck
• String handling that works
• Garbage collection (yes, there's a cost, but it's worth it)

Go is "worse is better" incarnate. It deliberately limits features to maintain simplicity. It refuses to add generics for years because they complicate the language. It has a GC because memory safety matters more than the last 5% of performance for most applications.

For web services, CLIs, and network tools? Go is perfect. It's C for people who want to ship code instead of debug pointer arithmetic.

This project isn't just a fun retro experiment or an exercise in nostalgia. It's proof of concept that the entire web industry chose wrong.

We didn't have to break backwards compatibility. The web didn't have to leave anyone behind. We could have:

• Maintained compatibility across 25+ years
• Still had modern features for modern browsers
• Reduced the digital divide
• Prevented massive e-waste (old devices could still be useful)
• Built simpler, more resilient architectures
• Avoided the framework churn treadmill

Instead we chose:

• "Rewrite your app every 3 years when the framework changes"
• "Requires Chrome 90+ released last month"
• "Sorry, your computer from 2015 is too old"
• npm hell and build pipeline nightmares
• Shipping megabytes of JavaScript to render a blog post
• "Best viewed in [current year's browser]"

And the industry is slowly admitting this (htmx, Astro, Remix, server components), but still won't go all the way back to true progressive enhancement because that would mean admitting we wasted 15 years.

When we abandoned progressive enhancement and backwards compatibility, we lost more than just support for old browsers:

1. Simplicity - A single HTML file could be a complete, functional application
2. Resilience - Sites worked even when JavaScript failed to load
3. Accessibility - Semantic HTML made screen readers work by default
4. Performance - Server-rendered pages loaded instantly
5. Longevity - Old sites still work decades later (if they followed standards)
6. Universal Access - The web was truly for everyone, not just the latest hardware

What did we gain?

• Developer convenience (debatable)
• Rich interactions (at massive cost)
• "Better" developer experience (subjective)
• Framework ecosystems (also: lock-in)

Was it worth the trade? This project suggests: probably not.

The uncomfortable realization is that we can't put the genie back in the bottle. The web has moved on. But we can learn from this:

1. Progressive enhancement still matters - Build for resilience, not just the happy path
2. Simplicity is a feature - Fewer dependencies = fewer problems
3. Server-side rendering works - It always has, we just forgot
4. Backwards compatibility is possible - We chose to abandon it, not forced to
5. "Worse is better" isn't just a slogan - It's proof that working solutions beat complex ones

Projects like this serve as reminders. The old way wasn't primitive - it was correct. We abandoned working principles for hype, then had to painfully rediscover them.

The modern web is finally circling back to admitting the old way was right, but with 10x the complexity and 0x the backwards compatibility.

This project runs a 2025 AI API on a 1999 browser. It shouldn't be remarkable, but it is - because we've convinced ourselves it's impossible.

Written after debugging CSS box model issues for an hour and having an existential crisis about the state of web development. The boxes finally stayed inside other boxes. Frontend is still chaos. We still chose wrong. Go is still great. "Worse is better" is still vindicated.