If you've been writing code for the web since the 1990s, you've watched entire technologies go from cutting-edge to punchline. Not all of them deserved it. Some were genuinely trying to solve hard problems. They just got solved better, somewhere else, by someone else, and then the platform caught up and made them irrelevant anyway.
Here's a look back at the tech that didn't make it, and what finally pushed it out.
SOAP to REST
SOAP (Simple Object Access Protocol) was never simple. It was XML over HTTP wrapped in a rigid envelope structure, with a formal contract defined by a WSDL file that you basically needed a degree to read. Enterprise software loved it. Developers tolerated it, then started letting code generators write it for them, then stopped using it entirely.
The shift to REST wasn't really a new technology. It was a new attitude. Roy Fielding had described REST in his dissertation back in 2000, but it took a few years before people started asking why they were generating 40 lines of XML to ask a server for a username. REST used the HTTP verbs you already had, returned data in whatever format made sense, and got out of your way. No envelope. No contract file. Just a URL and a response.
SOAP still exists in legacy enterprise systems, and some of those systems will outlive us all. But for anything greenfield, REST won decisively, and nobody misses writing WSDL by hand.
XML to JSON
XML wasn't just SOAP's problem. It was everywhere. Config files, data feeds, API responses, build tool output, you name it. Angle brackets as far as the eye could see.
JSON didn't beat XML because it was technically superior in every dimension. It won because it
was friendlier to read, cheaper to write, and in JavaScript, you could just eval()
it (please don't do that) and have a real object. As JavaScript became the dominant language of
the web, a format that mapped directly to JS objects had an obvious home-field advantage.
XML still has valid use cases. SVG is XML. RSS is XML. Some config formats still lean on it.
But as the default data exchange format for APIs and web apps, JSON took over so completely
that a lot of developers today have never written a line of XML outside of a Maven
pom.xml and a prayer.
Framesets to just... not doing that
The <frameset> was a real HTML tag that let you divide the browser window
into independently scrolling sections, each loading its own HTML document from its own URL.
This was how navigation worked on a lot of early websites. Your left sidebar was one file.
Your header was another file. Your main content area was a third.
<frameset cols="150,*">
<frame src="nav.html" name="nav" />
<frame src="content.html" name="main" />
</frameset>Users couldn't bookmark a specific page state in any meaningful way, because the address bar still showed the frameset's URL regardless of what was loaded in the frames. Back and forward buttons produced results that varied by browser and, seemingly, lunar phase. Search engines indexed the frameset page and found nothing, because the content lived in the frames.
The fix was the answer CSS almost always is: keep your content in one document. Once layout stopped requiring separate HTML files, framesets had nothing left to offer. They were formally obsoleted in HTML5. Nobody filed a complaint.
Iframes survived, and for good reason. They're still the right tool for embedding third-party content, payment widgets, and anything you want isolated from your page's JavaScript context. But that's a very different thing from using them to build your navigation system.
Flash to HTML5
Flash was magic. That's not nostalgia, that's just true. In an era when the web was mostly static pages and blue underlined links, Flash let you build animated, interactive experiences that felt like nothing else on the internet. Games, video players, interactive ads, entire websites that behaved like applications.
The problem was that Flash was a black box controlled entirely by Adobe. It was a plugin, not a platform. Mobile killed it more than anything else. When the iPhone shipped in 2007 without Flash support, and Steve Jobs wrote that open letter in 2010 laying out exactly why Apple wouldn't support it, the writing was on the wall. Battery drain, security vulnerabilities, and the rising capability of HTML5 canvas, CSS animations, and the video element did the rest.
Adobe officially killed Flash in 2020. The web moved on. Some of those old Flash games are being preserved by the Internet Archive, which feels right.
Java Applets deserve an honorable mention here. They were Flash's less-capable predecessor: required the JDK installed locally, took roughly four minutes to load over a 56k modem, and produced a gray box more often than a working application. Applets were already on their way out before Flash hit its peak. Most people who weren't coding in 1998 have only ever seen one in a browser security warning.
The HTML presentation era: <font>, <blink>,
<marquee>
Before CSS had any real purchase on layout and appearance, HTML carried the full weight of
presentation. This produced things like
<font face="Comic Sans" color="red" size="7"> nested inside
<center> tags, inside table cells, inside other tables.
The <blink> tag blinked text. That was its entire purpose. It was added
to Netscape Navigator in 1994 as something of a joke by engineer Lou Montulli, who later
said he regretted it immediately. It caused real accessibility problems and was eventually
removed from browsers. <marquee> was Internet Explorer's contribution:
horizontally scrolling text. It technically still works in some browsers today. No spec
editor has bothered to remove it because doing so requires a meeting, and nobody wants to
have that meeting about <marquee>.
The path out was CSS. The Web Standards Project spent years pushing developers and browser
vendors toward separating content from presentation. It worked, mostly. The last
<font> tag in production is probably inside an enterprise CMS somewhere,
lovingly preserved by a developer who retired in 2009.
document.all and document.layers to document.querySelector
This one's for people who remember the browser wars like a bad dream.
In the late 90s, Internet Explorer and Netscape were in a full sprint to differentiate
themselves, and they both invented their own ways to access DOM elements. IE gave you
document.all. Netscape 4 gave you document.layers. Neither
worked in the other browser. This forced developers to write forked code, detecting which
browser you were on and calling the right API.
// The dark ages
if (document.all) {
document.all['myDiv'].style.display = 'none';
} else if (document.layers) {
document.layers['myDiv'].visibility = 'hidden';
}
document.getElementById was a step forward when it became standard, but
document.querySelector and document.querySelectorAll were the
real turning point. CSS selector syntax, applied to the DOM, in a single consistent API.
It landed in browsers around 2008, and jQuery, which had popularized the selector approach,
suddenly had a lot less work to do.
IE conditional comments deserve a mention alongside this era. The pattern
<!--[if IE 6]>...<![endif]--> was a whole sub-genre of frontend
development: HTML comments that IE parsed as real markup. Developers used them to ship
targeted CSS hacks to specific IE versions. They worked. They were also deeply weird.
They were dropped in IE10 and never spoken of again.
XMLHttpRequest to Fetch
XMLHttpRequest made AJAX possible. That matters. It's the reason Gmail could load your inbox without refreshing the page, and it quietly changed what people expected a web app to be able to do.
But XHR was awkward. Verbose, callback-heavy, and not exactly a pleasure to read or write.
The Fetch API replaced it with a promise-based interface that felt modern and composable.
One line to make a request, .then() to handle the response,
async/await to make it read like synchronous code.
XHR still works in every browser. But outside of very specific compatibility cases, you'd choose Fetch every time today.
A few more worth mentioning
Some shifts happened faster and with less ceremony:
Table-based layouts to CSS. For years, pixel-perfect layouts meant nesting
<table> tags inside other <table> tags. CSS floats
replaced them, then flexbox and grid made floats feel just as archaic as the tables did.
It took longer than it should have, mostly because IE6 had a different idea about how
box sizing worked, and that idea was wrong.
document.write() to anything else.
document.write() injected HTML directly into the document during initial load.
It was synchronous, it blocked rendering, and the ad industry relied on it well into
the 2000s. If you called it after the page had finished loading, it wiped the entire
document and started over. Modern development mostly pretends it doesn't exist.
This is the correct response.
@import for CSS to bundlers. Concatenating CSS files
manually, or relying on separate HTTP requests for each stylesheet, gave way to Webpack,
Vite, and their friends. One build step, one optimized bundle.
Alert boxes for debugging to console.log. Yes, people
really did use alert() to debug JavaScript. Yes, it stopped the thread.
Yes, it locked the entire browser UI until you clicked OK. The fact that
console.log was available in Firefox's Firebug before it was standard
everywhere is the kind of thing that creates specific developer trauma responses.
FTP deployment to everything else. A meaningful chunk of the web was deployed by dragging files into an FTP client and watching the progress bar inch forward. No git. No CI. No rollback. You were live the moment the file finished uploading, and if you uploaded a half-written PHP file, so was the error. Git and proper deployment pipelines replaced this. It took longer to catch on than you'd expect.
The pattern across all of these is consistent. The old tech solved a real problem. Then it accumulated weight: complexity, vendor lock-in, friction from a world it wasn't designed for. Something simpler, or more composable, or better-aligned with where the platform was heading, came along and replaced it.
None of this was inevitable. Flash lasted longer than it should have because it was
genuinely useful. SOAP hung around because enterprises had already bought in. Framesets
were formally obsoleted a decade after we all stopped using them. And
<marquee> is, technically, still with us.
But the web has a way of gravitating toward whatever lets developers build faster with fewer surprises. And that, more than any spec or standards body, is usually what decides what stays and what gets a Wikipedia article in the past tense.