Seriously considering going back to static HTML

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.

Join the Conversation

  1. I really sympathise with you! I really can’t understand the madness of the web as it is today. The vast majority of what we view online could easily be achieved with a few kb of static HTML. I have archives of some of my old web pages, which were coded in static HTML 4 and they render fine on both phone screens and desktop monitors – and, with entire web sites weighing-in at less than 1.25 MB (they fit on an EXT2-formatted floppy disk), they load blisteringly-fast (despite the transfer rate of a floppy-disk being a maximum of probably about 100kb/second under real-world usage)! They don’t look particularly dated even today, either. We’re just overcomplicating things with unnecessary scripts, and in many cases spyware cruft. If you don’t need a flashy video, or if your real content requires scrolling past a massive pointless header-image to view, then don’t include those elements. And unless you’re running something like an online-shop, where pages have to be generated on-the-fly, there’s no need to use Javascript to identify a user’s browser, to then determine exactly which PHP script to use, to query an SQL database, to retrieve and generate a static, unchanging (or rarely-changing) article (and of course refuse to display the static article unless the user is browsing with the latest version of Goggle Chrome, running on the latest update of Microshaft Winspy 10)!

    The following link really fascinates me: I really love the ideas on that site, relating to all sorts of technology not just the logistics of a solar-powered site (and office).

    And this one contains a brilliant rant – err, I mean talk – about exactly what’s wrong with web pages today, and presents some solutions:

    1. Those are some fantastic links, James! Thanks for sharing them with me. I’ll be spending some time consuming the information on them. Excellent! I’m also glad to see that I’m not alone in my thinking. I’m glad to be getting back into coding my own HTML. Time to ditch the bloat. 😉

  2. I ditched WordPress for exactly the same reason. My present website is pure HTML/CSS. When everything is ready, I only need to sign into the server and upload complete files. Done and dusted.

    When the layout is in CSS, all I have to do is write the text in Markdown using a text editor, copy the .md or .txt into a Markdown-HTML converter (I often use the online ), and from there copy-paste the automatically created HTML into the content space.

    The only slight problem is hand-crafting the menus on every separate page as I don’t want to use PHP or JavaScript.

    1. Thanks so much for sharing this with me. It’s so great to connect with like-minded people. I’m finding the Internet has become so bloated and over populated with rich media content that really doesn’t add much of anything, other than to slow things down to a crawl. I’ve decided to do what I can to streamline and simply my own content, making it easier for me to do what I want to do. I’m having a wonderful time re-learning what I used to do so very well, not too long ago.

      I really like your website and the approach you took. Very effective and elegant. Nicely done!

  3. I love static HTML still. I’ve actually very rarely ever needed to touch Javascript because anything I’ve ever wanted, I can just do up in Notepad++ and call it a day. I handbuilt a site about a year ago (I don’t wanna look like I’m advertising anything but and had a sysadmin friend of mine bizarrely amazed at how simple all the markup was. That’s why I laugh at the whole “minifying” business–just make it less crufty and it’ll load faster. Simple as.

    It’s cool seeing someone love for Mozilla Composer too–I’ve been using the Retrozilla (which is a later Mozilla suite fork) Composer for my personal site, and it’s so refreshing. Sad that browsers don’t have anything like that built-in anymore.

    1. Thanks so much, and your site looks fantastic! It’s informative, yet simple to navigate and fast to load. Now that’s how to code a webpage. 😉

      Been enjoying SeaMonkey’s Composer, as well as Kate (the advanced text editor for the Trinity desktop suite). I’m so disappointed that Composer’s development is not (so to speak). But, I can understand why, as the small SeaMonkey team of developers are having a difficult time just keeping up with the regular necessary updates to the browser. End of an era, I guess.

      1. Thank you! Still pretty pleased with it.

        And out of curiosity, have you tried any of the Composer forks? There’s a couple out there now, BlueGriffon and KompoZer come to mind. I know Griffon especially supports HTML5 and all that good new stuff. So if you’re finding Seamonkey’s Composer a bit out of date, might be worth a look. (Half the reason I use the Retrozilla one is because it’s out of date, but that’s a story for another day…)

        1. I have tried KompZer a while back, but not BlueGriffon or Retrozilla. I might just have to give them a try again. Thanks for mentioning them!