Today I found my first website on a Zip disk.

Well, probably. I can't actually open it.

We're in the middle of a move right now. Boxes everywhere. That phase where you're pulling things out of closets and drawers that haven't been touched in years. And buried in one of those boxes was a Zip disk from my Champlain College days. Labeled in my handwriting.

This thing almost certainly has my final project on it. My first real website. Built in Dreamweaver with image maps and tables, because that's how we did it in 1999.

And I have no way to see it.

No drive. No adapter. Just a plastic square holding a snapshot of who I was twenty-six years ago when I was just figuring all of this out.

I stood there holding it for a while. Longer than I should have. Moving makes you do that. Every box is a decision about what still matters. But this one hit different. Because the thing on that disk? I'm still doing it. I never stopped.

Twenty-six years. Same craft. Completely different world.

That disk got me thinking about all of it. Everything that changed. Everything that didn't. And whether we've actually been moving in the right direction this whole time.

1999 Was a Different Planet

Let me set the scene for anyone who wasn't there.

In 1999, most people were still on dial-up. 56k if you were lucky. You designed websites for 800x600 screens. Maybe 1024x768 if you were feeling ambitious. You tested in Netscape Navigator and Internet Explorer 4 and hoped for the best.

There was no CSS layout. Not really. If you wanted to control where things went on a page, you used tables. Not data tables. Layout tables. You'd take your design, slice it up in Photoshop or Fireworks, export the pieces as images, and reassemble them inside a grid of table cells. That was the job.

Image maps were a big deal. You could take one graphic and define clickable regions on it using coordinates. It was like building a puzzle that people could interact with. You'd map out rectangles and polygons by hand. If someone resized their browser, the whole thing broke. But it felt cutting edge.

Dreamweaver was how a lot of us built things. WYSIWYG editing. You could see what you were making while you were making it. Drag and drop. Visual layout. It generated the code for you. And that code was absolutely terrible. But it worked. And more importantly, it let people start building without needing to understand every tag and attribute first.

The Tools That Shaped Us

But HTML and Dreamweaver were only part of the picture. If you really want to understand 1999, you have to talk about Flash and Director.

Macromedia Director was a powerhouse. Before the web as we know it existed, Director was how people built interactive multimedia. CD-ROMs. Kiosks. Presentations. It had its own scripting language called Lingo, and it could export to Shockwave for the web. Director was doing interactive content before most people even had a browser installed. It was heavy, it was complex, and it was incredible for its time.

Then there was Flash. And Flash changed everything.

HTML in 1999 couldn't animate. It couldn't do smooth transitions. It couldn't play audio or video without a prayer and a plugin. Flash could do all of that. Splash pages with animated intros. Interactive navigation. Games. Entire websites built as a single .swf file. It was the closest thing we had to a rich application experience on the web.

Flash had its own language too. ActionScript. And this is where things get interesting. ActionScript was one of the first times a lot of web designers encountered real programming. Variables. Functions. Conditionals. Event handlers. It was based on ECMAScript, which means it was a cousin of JavaScript. A lot of people who eventually became serious developers cut their teeth on ActionScript inside Flash. It was a gateway into thinking programmatically.

JavaScript existed in 1999, but it was a different animal. You used it to validate forms. Maybe swap an image on hover. Write a little status bar message that scrolled across the bottom of the browser. Nobody was building applications with it. Nobody was even thinking about that. It was a scripting language. A utility. Something you sprinkled on top of HTML when you needed a little interactivity.

The idea that JavaScript would eventually replace Flash, power entire application frameworks, and become the most widely used programming language in the world? Nobody saw that coming. Not even close.

And then there was PHP.

PHP in 1999 was barely PHP. It was a template engine. That's literally what it stood for at first. Personal Home Page. You had an HTML file and you could drop in little blocks of dynamic content. Pull a date. Show a visitor counter. Maybe connect to a MySQL database and display some records. It wasn't a programming language the way we think about programming languages today. It was glue. It was a way to make static pages slightly less static.

But here's what made PHP matter. You could learn it in a weekend. You could write it right inside your HTML. You didn't need a compiler. You didn't need a framework. You uploaded a .php file to a shared hosting account and it just worked. The barrier to entry was almost nothing.

Sound familiar? That's the same thing that made Dreamweaver matter. And Flash. And Director. The tools that shaped that era all had one thing in common. They let people start building without requiring a computer science degree first.

That's the part I think we've lost sight of.

The Barrier to Entry Used to Be Low

Back then, you could go from zero to a published website in an afternoon. You didn't need to install Node. You didn't need a package manager. There was no build step. No webpack. No transpiling. You opened a program, you made something, you uploaded it to a server with FTP, and it was live.

Was the code good? No. It was terrible. Table layouts are a hack. Inline styles are a maintenance nightmare. Font tags should have been a crime. But people were making things. Regular people. People who didn't call themselves developers. People who just had an idea and wanted to put it on the internet.

The web was supposed to be for everyone. That was the whole point. Anyone could view source, see how something was made, and learn from it. You could right-click, look at the HTML, and understand the building blocks of what you were seeing.

Try doing that on a modern website. View source on most pages today and you'll see minified JavaScript that no human can read. The building blocks are buried under layers of abstraction. We didn't just raise the barrier to entry. We built a wall around it.

What Actually Changed (And What Didn't)

Here's the thing. The web itself hasn't changed that much. At its core, it's still the same technology. A browser requests a document. The server sends back HTML. The browser renders it. That's it. That's the web.

CSS came along and gave us real layout tools. That was a genuine improvement. We stopped using tables for structure and started using them for actual tabular data. Floats were painful. Flexbox was a revelation. Grid was even better. These were real steps forward.

JavaScript grew up. And I mean really grew up. That little scripting language we used to swap images on hover? It ate everything. It absorbed what Flash and ActionScript did. Animations. Rich interactivity. Audio. Video. Full application logic. All the things we needed plugins for in 1999, JavaScript eventually handled natively. When Steve Jobs killed Flash on the iPhone in 2010, it wasn't because Flash was bad at what it did. It was because the open web had finally caught up.

Director disappeared even earlier. Shockwave faded out. The plugin era ended. And honestly, that was the right call. The open web should be built on open standards. But we lost something in that transition too. Flash and Director had visual timelines. Drag-and-drop animation. You could see what you were building. The tools that replaced them are more powerful, but they're also more abstract. The creative accessibility those tools offered never fully came back.

PHP grew from a template engine into one of the most widely deployed server-side languages in history. WordPress runs on it. Which means a massive chunk of the internet runs on it. It's easy to look down on PHP today. Developers love to joke about it. But PHP powered the dynamic web before most of today's languages even existed. And it did it by staying approachable. You didn't need to understand object-oriented programming or design patterns to get started. You just wrote some code inside your HTML and it worked.

Responsive design changed everything too. The idea that one website could adapt to any screen size solved a real problem. We went from building separate mobile sites to building fluid layouts that worked everywhere. That mattered.

But somewhere in the mid-2010s, something shifted. The tools started serving the tools instead of serving the people using them. We began optimizing for developer experience at the expense of simplicity. And the complexity just kept compounding.

The jQuery Era and the CSS Framework Treadmill

Before we talk about complexity, let me talk about jQuery. Because jQuery might be the most important JavaScript library ever written. And most people under thirty have no idea why.

In the mid-2000s, writing JavaScript for the web was a nightmare. Every browser handled things differently. Code that worked in Firefox broke in Internet Explorer. Code that worked in IE6 broke in IE7. You spent more time writing browser workarounds than actual functionality. It was exhausting.

jQuery fixed that. One library. Write your code once. It works everywhere. Dollar sign, selector, do something. It was clean. It was readable. It made JavaScript accessible to designers and backend developers who had been avoiding it. jQuery didn't just simplify JavaScript. It democratized it. Suddenly everyone could add interactivity to their sites without losing a week to browser debugging.

And jQuery was everywhere. At its peak, it was on something like 70% of all websites. It was the default. For a lot of developers, jQuery was JavaScript. They learned the library before they learned the language.

CSS went through its own evolution. After we finally killed table layouts, we had floats. And floats were a pain. Clearing floats. Float drops. The holy grail layout that required three different hacks to work. We needed help.

Blueprint CSS showed up around 2007 and gave us something we'd never had before. A grid system. Predefined columns. Consistent typography defaults. It was one of the first CSS frameworks, and it felt like someone had finally brought order to the chaos. You included the stylesheet, added some class names, and your layout just worked. No more fighting with floats from scratch on every project.

Blueprint paved the way for what came next. 960 Grid System. YAML. Foundation. And then in 2011, Bootstrap came along and changed the game entirely.

Bootstrap gave you everything. Grid system. Typography. Buttons. Forms. Navigation. Modals. Dropdowns. Responsive breakpoints. All of it, out of the box. You could build a professional-looking website in a day without writing a single line of custom CSS. It was Dreamweaver logic applied to the modern era. Lower the barrier. Let people build.

The tradeoff? Every Bootstrap site looked like a Bootstrap site. The internet developed a sameness. The same buttons. The same navbar. The same card layouts. You could spot Bootstrap from a mile away. But it worked. And for a lot of businesses, looking polished and consistent mattered more than looking unique.

Now we've got Tailwind. And Tailwind is a completely different philosophy. Instead of pre-built components, you get utility classes. Tiny, single-purpose class names that you compose directly in your HTML. It's polarizing. Some developers love it because it's fast and flexible. Others look at a div with twenty class names on it and feel like they're reading a different language.

Here's the pattern I want you to see. Blueprint. Bootstrap. Tailwind. Three different eras. Three different approaches. All solving the same fundamental problem: how do you make CSS manageable at scale?

The answer keeps changing. The problem doesn't.

The CMS Graveyard

You want to see the churn in this industry? Look at content management systems. The CMS landscape is a graveyard of tools that were going to change everything.

I've watched so many come and go.

Mambo was one of the early open-source CMS platforms that people actually used. It was popular. It had momentum. Then the community fractured and Joomla forked off from it in 2005. Mambo faded. Joomla carried on. That's how fast things moved.

Joomla had its moment. For a while it was a real contender. It sat right between WordPress and Drupal in terms of complexity. Not as simple as WordPress, not as developer-heavy as Drupal. But it never found a clear identity, and over time its community thinned out. It's still around, technically. But the energy is gone.

Drupal was the enterprise choice. The serious CMS. If you needed complex content types, custom workflows, granular permissions, Drupal could do it. I built a lot of projects on Drupal over the years. But it demanded a lot from you. The learning curve was steep. Updates could be brutal. Drupal 7 to Drupal 8 was essentially a full rewrite that left a lot of agencies scrambling. It pushed people away who didn't have the resources to keep up.

WordPress won. That's the simple version of the story. It started as a blogging platform and just kept expanding. Themes. Plugins. Page builders. Gutenberg. WooCommerce. It went from "I want to write blog posts" to "I want to run my entire business" and it pulled it off through sheer ecosystem size. Is WordPress the best CMS from a technical standpoint? No. But it's the one that made content management accessible to regular people. There's that word again. Accessible.

Along the way there were others. Expression Engine had its loyalists. Textpattern had its niche. Concrete5 tried something different with in-page editing. Squarespace and Wix showed up and said forget the CMS entirely, we'll just host everything for you. Craft CMS earned respect from developers who wanted something cleaner than WordPress but more approachable than Drupal.

And now we're in the headless era. Contentful. Sanity. Strapi. The CMS doesn't even render your website anymore. It just holds your content and serves it through an API. Your frontend could be React, Next.js, Astro, whatever you want. The CMS became a database with a nice editing interface.

Every generation of CMS solved real problems. And every generation eventually got replaced by something that solved those problems differently. The content never changed. People still need to publish words and images on the internet. The machinery underneath just keeps getting rebuilt.

That's the thing about this industry. We keep rebuilding the machinery.

The Complexity Trap

Let me be clear about something. I'm not against new tools. I'm not against frameworks. Some of them solve real problems. But the industry has a habit of reaching for complexity when simplicity would work just fine.

I've watched this cycle repeat for twenty-six years.

A new framework shows up. It solves a specific problem really well. People start using it for everything, even problems it wasn't designed for. The ecosystem around it explodes. Now you need twelve dependencies just to get a project started. Then a newer framework comes along, and the whole thing starts over.

Meanwhile, the fundamentals haven't changed. HTML still works. CSS still works. Vanilla JavaScript is more powerful than it's ever been. You can build impressive, fast, functional websites without a single framework. But try telling that to someone who learned to code in the era of create-react-app. They'll look at you like you suggested they write assembly.

We've created a culture where you feel behind if you're not using the latest thing. Where job postings list fifteen technologies for what amounts to a CRUD app. Where junior developers feel overwhelmed before they even start because the landscape looks impossibly vast.

It doesn't have to be this way.

AI Didn't Simplify Things. It Added a New Layer.

Now we've got AI in the mix. And I'll be honest. It's a powerful tool. It's changing how we work. I use it. My team uses it. We'd be foolish not to.

But it didn't simplify web development. It added another layer on top of everything else.

AI can generate code faster than any human. That's a fact. It can scaffold an entire application in minutes. But someone still has to understand what it built. Someone has to debug it when it breaks. Someone has to know whether the code it generated is good, secure, and maintainable, or if it's just code that happens to run.

Writing code was never the hard part. I know that's a spicy take, but I've believed it for twenty-five years. The hard part is comprehension. It's building a mental model of how a system works. It's understanding what happens when you change one thing and something else breaks three layers down. It's knowing the right approach before you write a single line.

AI doesn't give you that. Not yet. Maybe not ever. It gives you output. Understanding is still a human job.

And here's the irony. AI has actually made it more important to understand the fundamentals, not less. If you can't read and evaluate the code that AI generates, you're not using a tool. You're trusting a black box. That's a different thing entirely.

What the Trades Can Teach Us

I work with contractors every day. HVAC techs. Plumbers. Electricians. Roofers. These are people who build and fix real things with real consequences.

You know what they don't do? They don't chase the latest trend for the sake of it. They learn their trade. They master their tools. When a better tool comes along, they evaluate it based on whether it actually helps them do the job better. Not whether it's new. Not whether it's trendy. Whether it works.

A good HVAC technician doesn't need the fanciest equipment on the market. They need to understand refrigerant cycles, airflow, electrical systems, and how buildings work. The fundamentals. Give a great tech basic tools and they'll diagnose a problem faster than a mediocre tech with every gadget available.

Web development could learn something from that.

Know your fundamentals. Understand how the web works at a basic level. Then choose your tools based on what the project actually needs, not what the industry is hyping this quarter.

What I'd Tell the Kid on That Zip Disk

If I could somehow reach back through time to that kid sitting in a computer lab at Champlain College, building his first website with image maps and table layouts, here's what I'd tell him.

You're on the right track. The things you're learning right now, how HTML structures a page, how elements relate to each other, how a browser turns code into something visual, those things are going to matter for your entire career. The tools will change a hundred times. The fundamentals won't.

Don't let anyone make you feel like what you're building isn't real because you used Dreamweaver instead of writing code from scratch. You're learning how to think about building for the web. That's the skill. The syntax is just the language you use to express it.

Stay curious. Stay building. Don't over-complicate things.

Keep it simple. Make it look beautiful. Have it work.

The Disk Is Making the Move

I still can't open that Zip disk. I still don't have a drive. But it's packed in a box with my name on it. It's coming with us to the new place.

Not because I think what's on it is good. I'm sure it's terrible. Tables nested inside tables. Image maps with hardcoded coordinates. Dreamweaver-generated markup that would make modern linters crash.

But it's the start. It's proof that twenty-six years ago, a kid sat down at a computer and decided to build something for the web. And he never stopped.

The tools changed. The industry changed. The complexity grew in ways none of us could have predicted.

The curiosity didn't change. The fundamentals didn't either.

If anyone has a working Zip drive collecting dust somewhere in Vermont, let me know. This disk and I have some catching up to do.