qz thoughtsSo, Why Blosxom?
Although it was moderately popular when new, calling Blosxom a dead blog tool now is fairly accurate. No one is using it for new sites and many former power users — people dedicated and involved enough to write plugins &mhash; have abandoned the platform. So it probably bears answering "Why do I still want it?"
Here are some of the things Blosxom has going against it:
- No active development to lean on for community improvements.
- Somewhat simplistic hook model for plugins.
- Very rudimentary interpolation engine.
- Very easy to accidentally change posting time on posts.
- Without plugins, lacks many features considered standard now:
- Comments
- Post composer
- Search
- Search engine tools like
sitemapsupport - Cookies for analytics, user preferences, and/or user logins
The main selling points Rael Dornfest had for Blosxom, as I remember it, where:
- Edit posts without a post composer.
- Import and export of posts is trivial since they are all just individual text files.
- Small code base with easy install on your own server.
- Simple to create plugins.
Most of those are not things I think people appreciate. GUI composers are very common these days, some more WYSIWYG then others, but having buttons for bolding, dialogs for links, etc, seems to be a thing people want. And maintaining code, installing things on an Internet server, that seems to to be things people don't want. You can get started in Tumblr in seconds after getting an email address and an Internet connection. Finding somewhere to install a Perl script, configure it to work with a web server, and then "how do you add images?" is too much.
So you've got deliberate features people don't care about, and drawbacks people will quickly notice. Blosxom is a hard sell these days.
But for me, it is what I have always done. My first forays into web
page construction were done composed in vi, served by NCSA HTTPd,
and viewed in Mosaic on university computers. From there, moved to
a Unix shell account on an ISP by 1996. I had my own personal colocated
server serving content on my own personal domain name by 1997, and was
saturating a
T1
at times by 1998. All of that original work was 100% my HTML and CGI
coding. I wrote a CGI libary in 1999 that I still use for some personal
projects.
For work, I've used blogging tools like Moveable Type and Wordpress. I've used content management systems like Plone and Drupal. I've stored content in Berkeley DB files, MySQL, and Postgres. I've worked with content accelerators like Varnish, Fastly (which is basically Varnish managed by someone else), and Akamai. I understand how and why to scale horizontally or vertically in Internet deployments.
I like coming back to the simplicity of knowing how every bit of the page gets transmitted from the first line of the HTTP request to the closing <BODY> tag in the HTML. That's what I get out of Blosxom. It is tiny and knowable. I have to do more work to enable things, but I know what that work is or how to find out. Until I did it for the sitemap tool last week, I had never actually built a sitemap, only parsed them for site scraping. It wasn't a hard task from deciding to do it and having it completed, even if it was a task that wouldn't be necessary with other tools..
Last month, May 2020, qaz.wtf moved 21,650,398,268 bytes in web
content, that's without headers, an average of 8083 bytes per second
all month long. Most of that (68.9%) was from the
Unicode Toys
which are configured to send compressed-on-the-fly 100% text html
generated by CGI scripts I've 100% written.
Second biggest top level item was /favicon.ico, sadly a binary
file with a crappy name because Microsoft invented that concept.
Third this blog (including images and CSS).
If I were using Wordpress, I doubt the pages would be as small,
and if I were using Medium the Javascript alone per page would be more
than my blog HTML content put together.
I'm happy controlling it all and knowing where my byte budget goes.