What an incredible article. More than its impressive documented scope and detail, I love it foremost for conveying what the zeitgeist felt at each point in history. This human element is something usually only passed on by oral tradition and very difficult to capture in cold, academic settings.
It’s fashionable to dunk on “how did all this cloud cruft become the norm”, but seeing a continuous line in history of how circumstance developed upon one another, where each link is individually the most rational decision at their given context, makes them an understandable misfortune of human history.
This is such a great read for those of us who lived through it and it really should be Front Page on HN.
Really wished it added a few things.
>The concept of a web developer as a profession was just starting to form.
Webmaster. That was what we were called. And somehow people were amazed at what we did when 99% of us, as said in the article, really had very very little idea about the web. ( But it was fun )
>The LAMP Stack & Web 2.0
This completely skipped the part about Perl. And Perl was really big, I bet one point in time on the Web most web site were running on Perl. Cpanel, Slashdot, etc. The design of Slashdot is still pretty much the same today as most of the Perl CMS in that era. Soon after every one knew C wouldn't be part of of the Web CGI-BIN Perl took over. We have Perl Script all over the web for people to copy and paste, FTP upload CHMOD before PHP arrives. Many forums at the time were also Perl Script.
Speaking of Slashdot, after that was Digg. That was all before Reddit and HN. I think there used to be something about HN like Fight Club "The first rule of fight club is you do not talk about fight club," And HN in the late 00s or early 10s was simply referred as the orange site by journalist / web reporters.
And then we could probably talk about Digg v4 and dont redesign something if it is working perfectly.
>WordPress, if you wanted a website, you either learned to code or you paid someone who did.
There were a part of CMS war or blogging platform before it was called a blog. There were many, including those using Perl / CGI-BIN. I believe it was Movable Type Vs Wordpress.
And it also missed forums, Ikonboard based on Perl > Invision ( PHP ) vs Vbulltin. Just like CMS/ blog there used to be some Perl vs PHP forum software as well. And of course we all know PHP ultimately won.
>Twitter arrived in 2006 with its 140-character limit and deceptively simple premise. Facebook opened to the public the same year.
Oh I wished they mentioned about MySpace and Friendster. The Social Network before Twitter and Facebook. I believe I have have my original @ksec Twitter handle registered and loss access to it. It has been sitting there for years. Anyone knows how to get it back please ping me. Edit: And I just realised my HN proton email address hasn't been logged in for months for some strange reason.
>JavaScript was still painful, though. Browser inconsistencies were maddening — code that worked in Firefox would break in Internet Explorer 6, and vice versa.
Oh it really missed the most important piece of web era. Firefox Vs IE. Together we pushed Firefox to beyond 30% and in some cases 40% of Browser market share. That is insanely impressive if we consider nearly most of those usage were not from work because Enterprise and Business PCs is still on IE6.
And then Chrome came. And I witness and realise how fast things can change. It was so fast that without all the fans fare of Mozilla people were willingly to download and install Google Chrome. And to this day I have never used Chrome as my main browser. Although it has been a secondary browser since the day it was launched.
>Version control before Git was painful
There was Hg / Mercurial. If anything taking over SVN it should have been Hg. For whatever reason I have always been on the wrong side of history or mainstream. Although that is mostly a personal preference. Pascal over C and later Delphi over Visual C++, Perl over PHP. FreeBSD over Linux. Hg over Git.
>Virtual private servers changed this. You could spin up a server in minutes, resize it on demand, and throw it away when you were done. DigitalOcean launched in 2011 with its simple $5 droplets and friendly interface.
Oh VPS was a thing long before DO. DO was mostly copying Linode from the start. And that is not a bad thing considering Linode at the time was the most developer friendly VPS provider. Taking the crown from I believe Rackspace? Or Rackspac...
> For that, you needed CGI scripts, which meant learning Perl or C. I tried learning C to write CGI scripts. It was too hard. Hundreds of lines just to grab a query parameter from a URL. The barrier to dynamic content was brutal.
That's folk wisdom, but is it actually true? "Hundreds of lines just to grab a query parameter from a URL."
In practice you would probably parse all parameters at once and maybe use a library.
I recently wrote a survey website in pure C. I considered python first, but do to having written a HTML generation library earlier, it was quite a cakewalk in C. I also used the CGI library of my OS, which granted was one of the worst code I ever refactored, but after, it was quite nice. Also SQLite is awesome. In the end I statically linked it, so I got a single binary to upload anywhere. I don't even need to setup a database file, this is done by the program itself. It also could be tested without a webserver, because the CGI library supports passing variables over stdin. Then my program outputs the webpage on stdout.
So my conclusion is: CRUD websites in C are easy and actually a breeze. Maybe that also has my previous conclusion as a prerequisite: HTML represents a tree and string interpolation is the wrong tool to generate a tree description.
Good showcase. Your code will match the first parameter that has <param> as a suffix, no necessarily <param> exactly (username=blag&name=blub will return blag). It also doesn't handle any percent encoding.
> That's folk wisdom, but is it actually true? "Hundreds of lines just to grab a query parameter from a URL."
No, because...
> In practice you would probably parse all parameters at once and maybe use a library.
In the 90s I wrote CGI applications in C; a single function, on startup, parsed the request params into an array (today I'd use a hashmap, but I was very young then and didn't know any better) of `struct {char name; char value}`. It was paired with a `get(const char name)` function that returned `const char ` value for the specified name.
TBH, a lot of the "common folk wisdom" about C has more "common" in it than "wisdom". I wonder what a C library would look like today, for handling HTTP requests.
Maybe hashmap for request params, union for the `body` depending on content-type parsing, tree library for JSON parsing/generation, arena allocator for each request, a thread-pool, etc.
> Every page on your site needed the same header, the same navigation, the same footer. But there was no way to share these elements. No includes, no components.
That's not completely true. Webservers have Server Side Includes (SSI) [0]. Also if you don't want to rely on that, 'cat header body > file' isn't really that hard.
HTML was invented as an SGML vocabulary, and SGML and thus also XML has entities/text macros you can use to reference shared documents or fragments such as shared headers, footers, and site nav, among other things.
What a comprehensive, well-written article. Well done!
The author traces the evolution of web technology from Notepad-edited HTML to today.
My biggest difference with the author is that he is optimistic about web development, while all I see is shaky tower of workarounds upon workarounds.
My take is that the web technology tower is built on the quicksand of an out-of-control web standardization process that has been captured by a small cabal of browser vendors. Every single step of history that this article mentions is built to paper over some serious problems instead of solving them, creating an even bigger ball of wax. The latest step is generative AI tools that work around the crap by automatically generating code.
This tower is the very opposite of simple and it's bound to collapse. I cannot predict when or how.
I was also impressed and read the whole thing and got a lot of gaps filled in my history-of-the-web knowledge. And I also agree that the uncritical optimism is the weak point; the article seems put together like a just-so story about how things are bound to keep getting more and more wonderful.
But I don't agree that the system is bound to collapse. Rather, as I read the article, I got this mental image of the web of networked software+hardware as some kind of giant, evolving, self-modifying organism, and the creepy thing isn't the possibility of collapse, but that, as humans play with their individual lego bricks and exercise their limited abilities to coordinate, through this evolutionary process a very big "something" is taking shape that isn't a product of conscious human intention. It's not just about the potential for individual superhuman AIs, but about what emerges from the whole ball of mud as people work to make it more structured and interconnected.
Wow. This is an incredible article that tracks just about everything I’ve done with the web over the past 30 years. I started with BbEdit and Adobe PageMill, then went to dreamweaver for Lamp.
> At one company I worked at, we had a system where each deploy got its own folder, and we'd update a symlink to point to the active one. It worked, but it was all manual, all custom, and all fragile.
The first time I saw this I thought it was one of the most elegant solutions I'd ever seen working in technology. Safe to deploy the files, atomic switch over per machine, and trivial to rollback.
It may have been manual, but I'd worked with a deployment processes that involved manually copying files to dozens of boxes and following 10 to 20 step process of manual commands on each box. Even when I first got to use automated deployment tooling in the company I worked at it was fragile, opaque and a configuration nightmare, built primarily for OS installation of new servers and being forced to work with applications.
I did this, but I used rsync, and you can tell rsync to use the previous ver as the basis so it wouldn't even need to upload everything all over again. Super duper quick to deploy.
I put that in a little bash script so.. I don't know if you call anything that isn't CI "manual" but I don't think it'd be hard to work into some pipeline either.
This is a great overview of web tech as I more or less recall it. Although pre-PHP CGI wasn’t a big deal, but it was more fiddly and you had to know and understand Apache, broadly. mod_perl & FastCGI made it okay. Only masochists wrote CGI apps in compiled languages. PHP made making screwy web apps low-effort and fun.
I bugged out of front-end dev just before jquery took off.
"Virtual private servers changed this. You could spin up a server in minutes, resize it on demand, and throw it away when you were done. DigitalOcean launched in 2011 ..."
The first VPS provider, circa fall of 2001, was "JohnCompanies" handing out FreeBSD jails advertised on metafilter (and later, kuro5hin).
These VPS customers needed backup. They wanted the backup to be in a different location. They preferred to use rsync.
Four years later I registered the domain "rsync.net"[1].
Fantastic read. I did most of my web development between 1998 and 2012. Reading this gave me both a trip down memory lane and a very digestible summary of what I've missed since then.
However, some very heavy firepower was glossed over.. TLS/HTTPS gave us the power to actually buy things and share secrets. The WWW would not be anywhere near this level of commercialized if we didn't have that in place.
Great read. I have fond memories of all the tricks we used to amaze visitors and fellow developers.
Like using fonts that weren't installed on the visitors' computer using sIFR.
https://mikeindustries.com/blog/sifr
This article was amazing. I hope the author continues to update it.
I've been creating web pages since 1993, when you could pretty much read every web site in existence and half of them were just HTML tutorials. I've lived through every change and every framework. 2025 is by far the best year for the Web. Never has it been easier to write pages and have them work perfectly across every device and browser, and look great to boot.
45 comments
[ 2.7 ms ] story [ 69.9 ms ] threadIt’s fashionable to dunk on “how did all this cloud cruft become the norm”, but seeing a continuous line in history of how circumstance developed upon one another, where each link is individually the most rational decision at their given context, makes them an understandable misfortune of human history.
Really wished it added a few things.
>The concept of a web developer as a profession was just starting to form.
Webmaster. That was what we were called. And somehow people were amazed at what we did when 99% of us, as said in the article, really had very very little idea about the web. ( But it was fun )
>The LAMP Stack & Web 2.0
This completely skipped the part about Perl. And Perl was really big, I bet one point in time on the Web most web site were running on Perl. Cpanel, Slashdot, etc. The design of Slashdot is still pretty much the same today as most of the Perl CMS in that era. Soon after every one knew C wouldn't be part of of the Web CGI-BIN Perl took over. We have Perl Script all over the web for people to copy and paste, FTP upload CHMOD before PHP arrives. Many forums at the time were also Perl Script.
Speaking of Slashdot, after that was Digg. That was all before Reddit and HN. I think there used to be something about HN like Fight Club "The first rule of fight club is you do not talk about fight club," And HN in the late 00s or early 10s was simply referred as the orange site by journalist / web reporters.
And then we could probably talk about Digg v4 and dont redesign something if it is working perfectly.
>WordPress, if you wanted a website, you either learned to code or you paid someone who did.
There were a part of CMS war or blogging platform before it was called a blog. There were many, including those using Perl / CGI-BIN. I believe it was Movable Type Vs Wordpress.
And it also missed forums, Ikonboard based on Perl > Invision ( PHP ) vs Vbulltin. Just like CMS/ blog there used to be some Perl vs PHP forum software as well. And of course we all know PHP ultimately won.
>Twitter arrived in 2006 with its 140-character limit and deceptively simple premise. Facebook opened to the public the same year.
Oh I wished they mentioned about MySpace and Friendster. The Social Network before Twitter and Facebook. I believe I have have my original @ksec Twitter handle registered and loss access to it. It has been sitting there for years. Anyone knows how to get it back please ping me. Edit: And I just realised my HN proton email address hasn't been logged in for months for some strange reason.
>JavaScript was still painful, though. Browser inconsistencies were maddening — code that worked in Firefox would break in Internet Explorer 6, and vice versa.
Oh it really missed the most important piece of web era. Firefox Vs IE. Together we pushed Firefox to beyond 30% and in some cases 40% of Browser market share. That is insanely impressive if we consider nearly most of those usage were not from work because Enterprise and Business PCs is still on IE6.
And then Chrome came. And I witness and realise how fast things can change. It was so fast that without all the fans fare of Mozilla people were willingly to download and install Google Chrome. And to this day I have never used Chrome as my main browser. Although it has been a secondary browser since the day it was launched.
>Version control before Git was painful
There was Hg / Mercurial. If anything taking over SVN it should have been Hg. For whatever reason I have always been on the wrong side of history or mainstream. Although that is mostly a personal preference. Pascal over C and later Delphi over Visual C++, Perl over PHP. FreeBSD over Linux. Hg over Git.
>Virtual private servers changed this. You could spin up a server in minutes, resize it on demand, and throw it away when you were done. DigitalOcean launched in 2011 with its simple $5 droplets and friendly interface.
Oh VPS was a thing long before DO. DO was mostly copying Linode from the start. And that is not a bad thing considering Linode at the time was the most developer friendly VPS provider. Taking the crown from I believe Rackspace? Or Rackspac...
That's folk wisdom, but is it actually true? "Hundreds of lines just to grab a query parameter from a URL."
In practice you would probably parse all parameters at once and maybe use a library.I recently wrote a survey website in pure C. I considered python first, but do to having written a HTML generation library earlier, it was quite a cakewalk in C. I also used the CGI library of my OS, which granted was one of the worst code I ever refactored, but after, it was quite nice. Also SQLite is awesome. In the end I statically linked it, so I got a single binary to upload anywhere. I don't even need to setup a database file, this is done by the program itself. It also could be tested without a webserver, because the CGI library supports passing variables over stdin. Then my program outputs the webpage on stdout.
So my conclusion is: CRUD websites in C are easy and actually a breeze. Maybe that also has my previous conclusion as a prerequisite: HTML represents a tree and string interpolation is the wrong tool to generate a tree description.
https://www.joelonsoftware.com/2001/12/11/back-to-basics/
Yet 30 years later it feels like string interpolation is the most common tool. It probably isn't, but still surprisingly common.
No, because...
> In practice you would probably parse all parameters at once and maybe use a library.
In the 90s I wrote CGI applications in C; a single function, on startup, parsed the request params into an array (today I'd use a hashmap, but I was very young then and didn't know any better) of `struct {char name; char value}`. It was paired with a `get(const char name)` function that returned `const char ` value for the specified name.
TBH, a lot of the "common folk wisdom" about C has more "common" in it than "wisdom". I wonder what a C library would look like today, for handling HTTP requests.
Maybe hashmap for request params, union for the `body` depending on content-type parsing, tree library for JSON parsing/generation, arena allocator for each request, a thread-pool, etc.
Isn't that CURL?
> Isn't that CURL?
Curl sends requests, it doesn't handle incoming requests.
That's not completely true. Webservers have Server Side Includes (SSI) [0]. Also if you don't want to rely on that, 'cat header body > file' isn't really that hard.
[0] https://web.archive.org/web/19970303194503/http://hoohoo.ncs...
They cannot be arbitrary components though.
The author traces the evolution of web technology from Notepad-edited HTML to today.
My biggest difference with the author is that he is optimistic about web development, while all I see is shaky tower of workarounds upon workarounds.
My take is that the web technology tower is built on the quicksand of an out-of-control web standardization process that has been captured by a small cabal of browser vendors. Every single step of history that this article mentions is built to paper over some serious problems instead of solving them, creating an even bigger ball of wax. The latest step is generative AI tools that work around the crap by automatically generating code.
This tower is the very opposite of simple and it's bound to collapse. I cannot predict when or how.
But I don't agree that the system is bound to collapse. Rather, as I read the article, I got this mental image of the web of networked software+hardware as some kind of giant, evolving, self-modifying organism, and the creepy thing isn't the possibility of collapse, but that, as humans play with their individual lego bricks and exercise their limited abilities to coordinate, through this evolutionary process a very big "something" is taking shape that isn't a product of conscious human intention. It's not just about the potential for individual superhuman AIs, but about what emerges from the whole ball of mud as people work to make it more structured and interconnected.
That's what I still do 30 years later
The first time I saw this I thought it was one of the most elegant solutions I'd ever seen working in technology. Safe to deploy the files, atomic switch over per machine, and trivial to rollback.
It may have been manual, but I'd worked with a deployment processes that involved manually copying files to dozens of boxes and following 10 to 20 step process of manual commands on each box. Even when I first got to use automated deployment tooling in the company I worked at it was fragile, opaque and a configuration nightmare, built primarily for OS installation of new servers and being forced to work with applications.
I put that in a little bash script so.. I don't know if you call anything that isn't CI "manual" but I don't think it'd be hard to work into some pipeline either.
I kind of miss it honestly.
I bugged out of front-end dev just before jquery took off.
The first VPS provider, circa fall of 2001, was "JohnCompanies" handing out FreeBSD jails advertised on metafilter (and later, kuro5hin).
These VPS customers needed backup. They wanted the backup to be in a different location. They preferred to use rsync.
Four years later I registered the domain "rsync.net"[1].
[1] I asked permission of rsync/samba authors.
"... and through it all, the humble <br> tag has continued playing its role ..."
However, some very heavy firepower was glossed over.. TLS/HTTPS gave us the power to actually buy things and share secrets. The WWW would not be anywhere near this level of commercialized if we didn't have that in place.
I've been creating web pages since 1993, when you could pretty much read every web site in existence and half of them were just HTML tutorials. I've lived through every change and every framework. 2025 is by far the best year for the Web. Never has it been easier to write pages and have them work perfectly across every device and browser, and look great to boot.