The 30-Year Stack: Everything Changes, Nothing Changes

In 1995, I got my first home internet connection and built my first web page. Static HTML. No frameworks, no build tools, no deploy pipeline, no CI/CD, no Kubernetes, no microservices.

Just a file that a browser turned into something you could see.

I was hooked.

The Beginning

By 1996, I was in college on a work-study job writing CGI Perl scripts. The task was beautifully simple: take a spreadsheet of student grades and turn it into a web page. The professor would update the spreadsheet, my script would translate it, and students could check their grades in a browser.

That was cutting-edge.

By 1997, I'd landed an internship at a major internet company, building landing pages for ad campaigns and cranking out banner ads. This was the era when getting a website was still a competitive advantage, not a baseline expectation. If your business was online at all, you were ahead.

I didn't know it then, but I'd just started a career that would teach me the same lesson over and over again for the next three decades.

The Cycle

If you've been in web development long enough, you've watched the same pattern repeat:

Static pages → We built everything by hand. Every page was an HTML file. It was tedious, but it worked. The browser rendered it, and people saw your content.

Dynamic, CMS-driven applications → We got tired of managing hundreds of static files, so we built content management systems. Databases, server-side rendering, templates. Suddenly a marketing person could update the website without calling a developer. Revolutionary.

Back to static pages → Then we realized dynamic sites were slow. Every page request hit a database, ran through a template engine, assembled HTML on the fly. So we invented static site generators. Take all that dynamic content and... pre-render it into static HTML files. Sound familiar?

Headless CMS on top of everything → We decoupled the content management from the presentation layer. APIs everywhere. GraphQL. REST endpoints. Webhook-triggered builds. A massive architecture to... generate static HTML files that a browser renders.

Back to static pages again → JAMstack. Netlify. Vercel. The entire pitch was "static sites, but modern." We built an entire ecosystem of tools, services, and billion-dollar companies around the idea that pre-rendered HTML is fast and reliable. Which is exactly what we had in 1995.

And now: AI agents that build websites while I talk to them.

I can have a conversation with an AI, describe what I want, and watch it write code in real time. It pulls from hundreds of libraries, coordinates multiple services, and assembles a complete web application in minutes.

And what does it produce?

HTML. Rendered in a browser.

The Part That Breaks My Brain

Here's where it gets weird.

We've spent 30 years adding layer upon layer of abstraction. Hundreds of JavaScript libraries. Build tools that compile code written in languages that compile to other languages. AI agents that orchestrate other AI agents. Container orchestration platforms running on cloud infrastructure managed by other cloud infrastructure.

All of it, Every framework, every tool, every revolutionary paradigm shift — exists to do one thing: produce HTML that a browser can parse and display on a screen.

The browser doesn't care how you got there. It never has.

But it gets weirder. Now the "user" consuming that HTML isn't always a person. It's another AI. ChatGPT, Perplexity, Claude — they're browsing the web, reading the HTML, and re-rendering the content inside their own interfaces.

An AI wrote the HTML. Another AI is reading it. The browser in the middle is doing exactly what it did in 1995: parsing markup and showing it on a screen.

What Our Industry Gets Wrong

I've watched developers (myself included) chase every new framework, every new paradigm, every "this changes everything" moment. And I get it. New tools are exciting. They solve real problems. They make certain tasks faster or more elegant.

But somewhere along the way, we started confusing the layers with the foundation.

I've met senior developers who can architect a microservices system but can't explain how CSS specificity works. Engineers who deploy to Kubernetes but have never thought about what happens between the browser receiving HTML and the user seeing pixels on the screen.

The foundation hasn't changed. The browser receives a document. It parses the HTML. It applies the styles. It runs the scripts. It renders pixels. That's been the deal since the beginning.

Every framework is an abstraction on top of that process. Every tool is a way to generate or manage the inputs to that process. Every AI agent is automating parts of that process.

But the process itself? It's the same one I learned in 1995.

Why This Matters

If you understand how HTML renders in a browser, really understand it, you have an advantage that doesn't expire. Frameworks come and go. Build tools rise and fall. Programming languages gain and lose popularity.

But the browser's fundamental job hasn't changed in 30 years, and I don't think it's going to change in the next 30.

This is why I still tell every client the same thing I told them in 2005, and 2015, and last Tuesday: your website's job is to deliver content to a browser in a way that's fast, accessible, and clear. Everything else is a means to that end.

The companies that understand this build websites that last. The ones that don't end up rebuilding every two years, chasing whatever framework just hit the top of Hacker News.

What's Next?

I've been doing this for 30 years. In that time, the web has gone from a curiosity to the backbone of modern commerce, communication, and culture. The pace of change has accelerated beyond anything I could have predicted when I was writing Perl scripts in a college computer lab.

So what will the next 30 years bring?

Honestly, I'm not sure "30 years" is the right timeframe anymore. At the pace AI is moving, maybe the question is what will the next 30 months bring. Or 30 minutes.

But I'll tell you one thing I'm pretty confident about:

Whatever it is, it'll probably still output HTML.