And then someone realized that more compelling sites made more money, and technology has been accelerating ever since.

Today’s web is a swirling vortex of competing financial interests, held in check by bandwidth, viewports, and browser adoption. But to understand how we got here, we need to glance back at where we’ve come from.

Tables for Layout

The classic example of a hack gone awry is using tables for layout.

Because it hadn’t occurred to anyone that data would need to be designed, there was no way to position it. Tables were introduced to the HTML specification to display tabular data, but tables looked a bit like a designer’s layout grid, and it worked, so we used them.

It might sound crazy now, but there was plenty to endorse the original hackaround:

• It worked — it is hard to impress upon young designers quite how broken the early web was. Tables, unlike literally everything else, worked consistently across browsers.
• Shallow learning curve — web design was all self-taught, and tables looked a lot like grids in print design. And that was one less thing to learn.

As you’ll see in the rest of this post, most web technology is killed off by newer technology that does the job better. In the case of tables, along came CSS, and complex HTML code with dozens of nested tables was a thing of the past.

Their misuse by a generation of web designers gave tables a terrible reputation—I still meet people who confidently inform me that table elements are deprecated. (Tables are perfectly fine, just not for layout.)

Text as Images

The story of the web is very much the story of designers being told “No!” And doing it anyway. Not content with using tables for layout, early-era web designers regularly embedded text in images.

In those days, there was no Google Fonts. Actually, there was no Google. Font embedding wasn’t even on the horizon. Web pages used Arial, Times, Verdana, Courier, or — my personal favourite — Georgia.

Not to be held back by something as petty as common sense, designers lost patience with the glacial pace of typography enhancements on the web and started embedding text in images. And not just headings; whole web pages were rendered as images.

Ever wondered why Photoshop has all those 3D emboss effects? It was to cater to 90s web designers determined to make their text “pop.” Of course now we know that text in images was horrific for accessibility, slowed sites down, and was impossible to update. And we knew it then as well; we just didn’t care.

Once again, CSS saved us from ourselves. But before it did, we’d already started to dial it in. Our obsessive need to use real italics gave way to an acceptance that sites don’t have to look identical on every browser, and the web became a little saner.

Image Maps

Of course, if you’re going to insert all of your text in an image, you’re going to need a way of making the text clickable. Cue: image maps.

Image maps were a technique in web design that allowed you to define clickable hot spots within an image. That way, your entire menu could be an image, and you could create multiple hit areas corresponding to the skeuomorphic buttons you’d spent days creating in Fireworks.

Image maps were a hacky workaround that offered no benefit other than enabling bad habits like embedding text in images.

Thankfully, as we moved towards a more accessible web powered by CSS, image maps ceased to offer any benefit at all, and their use petered out.

Web Directories

In 2023, the web is driven by SEO; every major decision about a website involves a deep strategic analysis of how the available options will play out on search engines.

But in the late 90s, we’d never heard of Alta Vista, let alone Google. And so, when we wanted users to discover a new site we’d made, we posted it to a web directory.

Web directories like DMOZ were human-curated collections of links. That’s right, there were so few websites online that you could list them all in a few dozen categories. Even when search engines began to appear, you still submitted your site to web directories because search engines had very limited crawl capabilities, so the only thing they crawled with any regularity was web directories.

Web directories would be impossible to maintain now, but 25 years ago, they offered several benefits that SEO has yet to beat:

• Human editing — web directories were human-edited, meaning that every site on display had been vetted for quality by an actual person.
• Browseability — you didn’t need to know what you were searching for on web directories; you just clicked around a topic that interested you. It was like a mega-menu for the web.
• Creativity — search engines value consistency, and humans value novelty. Web designers have never been more creative than when Google simply did not matter.

The switch from web directories to search engines was essential for the health of the web as it grew. But SEO is still struggling to meet the same quality assurances of the best web directories.

Frames

In the era before CMS ushered in templates, it was all too easy for inconsistencies to creep into websites. A menu had to be copied and pasted into every static page, and any updates had to be made on every page.

Frames allowed designers to load different parts of a site into different regions of a page. Suddenly, you could code your menu once and load it via a frame into every page on your site. Frames offered:

• Organization — it was kinda OOP for HTML. Kinda.
• Development speed — reusable code meant shorter development times and added consistency.

Unfortunately, the cons of frames far outweighed their pros:

• Poor usability — browsers never quite got to grips with frames, and functionality like bookmarks was never implemented properly.
• SEO issues — web crawlers struggled to index frames properly, so as SEO grew in importance, frame-based sites suffered.
• Accessibility issues — frames were dreadful for speech browsers. In truth, most early websites were terrible for accessibility, but frame-based sites were among the worst.
• Blackhat and security — it wasn’t always obvious where a frame’s contents were being linked from. If you thought hot-linking images was bad, wait until someone hotlinks your whole site.

We still use iframes on the web, but the original frames approach was thankfully killed off by CSS and templates.

Flash & Actionscript

Flash was nothing less than a revelation when it rose to prominence around the millennium. Initially marketed as an animation tool by Macromedia, it was version 5 that was the game-changer by expanding its rudimentary stop() and play() commands into a fully formed coding language called Actionscript.

By version 6, Actionscript had evolved into an object-orientated programming language with power comparable to modern-day JavaScript.

The success of Flash was thanks to its multiple benefits:

• Browser-agnostic — Flash ran in the Flash player. And so, it didn’t matter what browser your users preferred; your site would be identical on all of them.
• Liquid design — a forerunner of responsive design, liquid design saw Flash designers employing techniques that allowed a web page to resize with the viewport.
• Vector graphics — Flash used vector graphics, ensuring that sites looked crisp (as crisp as 96ppi can look).
• Font embedding — use any font you like; simply embed the outlines.
• Audio and Video — rich media was simple to implement in Flash, at a time when it really didn’t work in browsers.
• Components — a forerunner of WordPress plugins, components allowed you to drop code from other developers right into your project.

Clearly, it was the greatest invention since moveable type; just don’t mention:

• Performance issues — Flash ate up power. If you were lucky enough to actually own a mobile device (few people did), then a single site could drain your battery to zero.
• Security issues — when Adobe acquired Flash from Macromedia, it had to recoup the cost by releasing more features. Shortened development cycles might have introduced one or two eeny-weeny security vulnerabilities.
• SEO issues — initially, Flash wasn’t indexed by search engines. The problem was resolved in (if memory serves) around a year, but reputationally, Flash never recovered.

The final nail in Flash’s coffin came when Apple refused to allow the Flash player to be installed on the fledgeling iPhone. They cited performance and security issues, but it was widely understood at the time that Apple feared Flash would allow developers to circumvent Apple’s lucrative App Store plan.

When denial eventually gave way to the cold light of reality, the most common phrase heard in Flash studios around the globe was, “Hey, have you seen this jQuery thing?!”

jQuery

Flash taught designers that not only could they code but that coding enhanced their designs. Unfortunately, the closest alternative to Actionscript was JavaScript (they are both based on ECMAScript) JavaScript early-2000s JavaScript really sucked.

And then, along came jQuery. jQuery was a library that abstracted JavaScript into something that made sense.

• Simplicity — what took JavaScript 18 lines of code, jQuery managed in two.
• Cross-browser compatibility — jQuery ironed out the inconsistencies between browsers, so we didn’t have to write browser-specific versions of code.
• AJAX — one of the most challenging tasks to implement in vanilla JavaScript was AJAX. jQuery made it simple, revolutionizing how we loaded data in HTML pages.
• DOM manipulation — jQuery made DOM manipulation simple, allowing all kinds of complex interactions that had previously only been realistic in Flash.

jQuery is still with us and used in plenty of projects. Many people will tell you that it’s too big. It’s actually the size of a single, very small image, but as we’ve seen, bad reputations are hard to shake.

For many tasks, jQuery has been replaced by more modern frameworks like Vue, Angular and React. However, the biggest challenge to jQuery is vanilla JavaScript, which has got its act together and introduced modern code inspired by the example jQuery set.

AMP

Our final technology of yesteryear is Accelerated Mobile Pages (AMP). Introduced in 2015, the stated goal was to improve website performance on mobile devices.

AMP worked by reducing the amount of HTML, CSS, and JavaScript available to designers. It forced designers to be restrained, which meant:

• Faster load times — streamlined code meant AMP could be served faster on mobile devices.
• SEO boosts — initially, Google favored AMP sites in its mobile search results, offering a clear advantage to any site that adopted the approach.

But the bad outweighed the good:

• Limitations — rather than optimizing sites, AMP simply limited them. Restrictions of what could be done in AMP made sites lacklustre.
• Google — no one is saying that AMP was Google’s attempt to seize control of web infrastructure by creating a two-tier web. No one is saying that. No one at all.

AMP met its (unofficial) end when Google bowed to pressure and began indexing all sites on mobile search, effectively removing the only benefit AMP provided.

What’s Next?

What web technology will we see the end of next? Surely, the humble JPG’s days are numbered; React is looking a little long in the tooth; inline styles must be doomed.

What we know for sure is that no technology is perfect, and when a new technology arrives, it replaces what came before it.

Who knows, perhaps even HTML won’t be with us forever…