7 ms·
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
by sharkjacobs 10y ago
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.
- davewiner 10y agoThat was the year we did the first browser-based blogging software. It's when Edit This Pager was invented. The first wave of bloggers. The name weblog. It basically came together in 1999.
- zeveb 10y agoI served my first webpages via Userland Frontier — thanks for building such a neat product all that long ago!
- peterwwillis 10y agoOh my god. Frames. The horror... 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.
- toomanybeersies 10y agoA CGI script to cat the posts together sounds like the better option. 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.
- peterwwillis 10y agoNah, it was too CPU intense. In addition, even though disks haven't gotten significantly faster since then, filesystems were a lot less advanced, and disk, virtual memory and CPU caches were much smaller. 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.
- sharkjacobs 10y ago> most web hosters would not provide database access without charging > 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
- MustardTiger 10y agoYes, PHP had already largely supplanted perl cgi scripts by 1999.
- spc476 10y agoMethinks you are selling older computers short. I ran my blog (up through 2005, maybe to 2006) on a 50MHz 486 with 32?MB RAM (maybe 64MB? It's been a decade) and a gig hard drive. That same server was also my email server. Then again, I wrote my own blogging engine in C [1] (and still use it). [1] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog
- cyphar 10y ago+1 for GPLv2 or later. :D
- peterwwillis 10y agoSure, you could do plenty with old 486's. But not hosting thousands of weblogs generating dynamic content. Not without load shooting up to 100, anyway. For a paltry few visitors, not so bad, but the more users and higher the traffic the worse it'd get. 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.
- jcd748 10y agoThat was how I did it, too. Monthly, I'd archive posts, to allow archive perusal by months. I wasn't tied to any particular software. I got hosting with friends who set up their own blogs at their own domains. All of us were in or just out of high school, no real plans for the future, lots of free time to post and talk over AIM/MSN. 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.