30 years of <br> tags

> 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.

[0] https://web.archive.org/web/19970303194503/http://hoohoo.ncs...

> 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 wanted this to end with something like:

"... and through it all, the humble <br> tag has continued playing its role ..."

Very nice article.

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.

> 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."

    /*@null@*/
    /*@only@*/
    char *
    get_param (const char * param)
    {
        const char * query = getenv ("QUERY_STRING");
        if (NULL == query) return NULL;

        char * begin = strstr (query, param);
        if ((NULL == begin) || (begin[strlen (param)] != '=')) return NULL;
        begin += strlen (param) + 1;

        char * end = strchr (begin, '&');
        if (NULL == end) return strdup (begin);

        return strndup (begin, end-begin);
    }

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.

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.

"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].

[1] I asked permission of rsync/samba authors.

Im only half way through, but just wanted to share that I love this kind of write up

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 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.

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.

> All I needed was Notepad, some HTML, and an FTP client to upload my files

That's what I still do 30 years later