Don’t get me wrong, I have enjoyed the convenience of posting content on the Internet with the help of dynamic web applications, like Dokuwiki and Flatpress.  But recently I decided to take a closer look at how I’ve been using them and try and figure out how much work and effort it actually takes for me to post content on the Internet using them.

Side Note: I’m not going to look too closely at my efforts with my Vivaldi blog, as I don’t have any control as to what web application they provide.  But, just for the record, I find WordPress to be one of the most bloated and complicated web-based application out there.

At the moment I maintain a few websites, four for my own personal blogs, a e-shop for my wife, and a website for our village’s community centre where I volunteer.  I’ve chosen a couple of different platforms to host/maintain them, including Dokuwiki, WordPress, FlatPress, and OpenCart. In general, the platforms look good and perform well.  Apart from WordPress (as I find it to be the most cumbersome to use), they are also easy enough to manage and maintain; although each of them have their own idiosyncrasies and limitations.

One thing, however, that is probably the most important aspect of these server-side dynamic web page publishers is that they are server side.  All of the content is stored on the cloud.  I do make backups of my websites, but the backups I have on my PC storage devices is just the content and I can’t really view the content off-line.  I guess I can view the raw data (in text form), but to see how it all looks in a web browser, I need access to the Internet.  So, if I want to work on any of my web pages, I need the Internet.  Typically, this wouldn’t be a big issue if we were always connected to the Web with unlimited bandwidth, but we don’t have this level of service where we’re living.

I’ve been thinking about how I used to publish my web content.  I used SeaMonkey’s Composer for creating my HTML content (before SeaMonkey it was Bluefish) and then KDE’s Konqueror file browser and the fish:// protocol as the go between for my home PC and server.  I would work to my heart’s content on my content locally, getting it to look just the way I want, then upload the HTML and images to the server when I was done.  I didn’t have to worry about account passwords to each of the administration pages on each website, nor did I have to worry about someone hacking via the same route.

It may have taken a bit more effort on my part to get everything all setup in the beginning, but maintenance was easy and I didn’t have to conform to the framework of the platform.  And because it was simple HTML and didn’t have to rely on any server side processing, they were fast.

As I think about it a little more, moving back to static HTM webpages may actually save me a lot of work in the long run.  Right now with the different platforms I use, when i write content for blogs and such, I usually first compose the work in another application (like a word processor).  Then, when I think that the work is close enough to being done for the Web, I have to cut and paste from that document into the on-line editor.  Very rarely is it a simple copy-paste; I usually have to reformat for the particular site and it’s platform.  This includes formatting for hyper-links or links to pictures, etc.

But, if I move to static HTML and use Composer instead, it may just be a lot less work for me.  Because Composer is both a WYSIWYG editor and an HTML coder, I can do all the work in that without having to worry about reformatting later on.  It also has some “smarts” in it, so pasting a huge block of text from another data source doesn’t take a lot of effort to format for the Web.

So now I’m wondering, should I try and do a static version of one of my website an see how it goes.  I’m thinking of maybe starting with my Commodore site (currently using Dokuwiki), as it has a wide range of content to test.  It will give me a great model to see if I could make a site that looks and performs just as well as a dynamic content publisher with nothing more than simple HTML.  The question to me is, do we really need all of the extra bloat of the “interactive” and dynamic web platform to share content on the web in an appealing and effective way?  I think static HTML may still has a meaningful place on the Web today.

Since deciding to try this, I have spent some time in Composer, getting some ideas for the design of the new site and getting my HTML “sea legs” back.  I’m actually enjoying getting back into it and regaining direct control over how my website looks and performs.  There’s an appreciation of how things work with the entire do-it-yourself philosophy.  This process also reminds me about why I enjoyed working with the SeaMonkey web suite in the past. The HTML “Composer” is a really great piece of software.  I’m having fun working with it again.

Watch this space as I share my experiences going forward with this.

---