When I was blogging in 1999 it involved appending each new blog entry to the top of the html page which went in the content frame.
And I don't think I'd heard of "blogging" yet.
And I don't think I'd heard of "blogging" yet.
In retrospect it was primitive, and it worked. There was a huge scene around all this - everyone had their blogs, and those with an eye for colour and design were doing cutting-edge presetation in idiosyncratic ways. I really miss this when taken against today's single-page, "FOL.IO IS A PLATFORM FOR MANAGING WORMS" type of web.
mc's online journal was what drew me into all of this. It's been offline for probably 20 years now, but it was deeply personal and intense, and wonderfully written.
We used to append content into a single page because the alternatives were A) independent post files and a cgi script to concatenate them dynamically on each view, or B) re-create the static page from individual post files.
Since using a database was totally overkill, and static + individual posts wasted precious megabytes, and a new dynamic process per page load was way too CPU-intense, we just curated a single static page. Saves disk and CPU. When posts got past a certain number, the process'd do some juggling of content into a new archive file.
That same server was also my email server.
Then again, I wrote my own blogging engine in C [1] (and still use it).
I should add that I completely forgot (has it been that long?) about the hacks we'd use to speed up dynamic content. Since there were no competent threading models for PHP and Perl at the time, we would use either FastCGI, or mod_php or mod_perl. The former would allow you to build app servers to handle multiple requests without terminating, to speed up initialization and share/cache memory. The latter would embed a PHP or Perl interpreter in the Apache process, eliminating lots of overhead, enabling better communication, and of course allowing you to prefork multiple Apache processes and execute scripts as soon as a request came in, and optionally stay resident in memory. But that's just execution speed; if you're reading from flat-files and spitting them out one by one, that's still a very i/o-bound operation and eats up more CPU than necessary.
And ultimately, very few web hosts allowed using mod_perl or mod_php, and no weblog maintainer ever wrote FastCGI (nor were the servers configured for it). So everything was forked at run-time, leading to very slow page loads for any CGI script - unless you ran your own server, of course. It wasn't until later that LAMP development became more common and people started putting the kitchen sink into MySQL and PHP.
Wasn't this the sort of thing that PHP was literally invented to do? Upon saying that, I have no idea what the state of PHP was in 1999.
PHP did develop quickly in order to optimize the performance of serving scripted web content. Besides its own performance enhancements it also relied heavily on database storage for content, which significantly improved performance for complex websites.
But it was mostly useless to people with just a homepage and guestbook; most web hosters would not provide database access without charging, and most web devs needed a higher level of technical competency to use them. A lot of websites were run by people who only knew front-end programming and markup languages.
> most web devs needed a higher level of technical competency
> websites were run by people who only knew front-end programming and markup languages
That was exactly my situation