Superfluous & Advanced

Redesign pt.3

This is the Final Part of a Three Part Blog Series. Although the focus of this Editorial series is an in-depth look at the latest redesign of this site, you may read these posts as letters of appreciation to the Basics of the Web.

  1. Structure & Semantics
  2. Style & Delight
  3. Superfluous & Advanced

The order of the three parts is not random, the most important one came first. You are reading part 3, which deals with the superfluous and advanced stuff, i.e. JavaScript.

Without further ado

In 2016, I had this to say about JavaScript:

Granted, it can do amazing things, but it also breaks easily if things go awry, and unlike HTML and CSS it does not come with a fail-safe mechanism. Which is why we need JavaScript even less than CSS.

No change of mind in those last four years. With that attitude, and this final part of my redesign series being all about JavaScript, it seems we can keep it short. Is there any JavaScript on this site?

Surprise, yes. For starters, the whole thing is generated by a static site generator written in JavaScript. But this blog series is about the visitor’s experience, so we’re talking client-side JavaScript. Is there any?

Again, yes. I wrote a little script that does some feature detection, primarily to ensure support for CSS variables. This is the fork in the road.

  • For browsers that don’t, the regular stylesheets will be replaced with supercharged print styles. (Why? Well, if a piece of paper can handle it, maybe Internet Explorer can too.)
  • For capable browsers on the other hand I start the progressive enhancement. But so far, the only enhancement is adding PrismJS to apply syntax highlighting.

What I’ve just described has been true even before the redesign, with only minor differences. More recently I came up with quite a few ideas how to make use of JavaScript on my site, if I ever find the time. But none of them are essential, so I wouldn’t mind if they never see the light of day.

One more thing

Also in 2016, I did not answer how I add Twitter conversations as comments to my articles. Nor did I last year. How about I use this opportunity to give you the harsh truth?

If you print (or remove all styles from) the home page of this site, you’ll notice it says in the footer that I am the curator of this site. Among all other things, I get to decide how comments are presented on every page. Now imagine multiple comments being written in a short period of time for a particular topic. If they belong to different threads, the threads will be presented one after the other, instead of comments being added individually in chronological order. Sounds like something a threaded commenting system can handle, right? Sure, but there’s no such thing here. No system whatsoever. Comments come exclusively from remote sources, mainly Twitter. What’s going on over there can at best be described as chaotic. And let’s not forget, sometimes a series of comments may be a response to an article I’ve written, but at other times a single comment or thread may be it’s own article.

Granted, tweets can be retrieved automatically, and even some of the things I’ve just mentioned can be automated, e.g. by looking at in-reply-to links, but let’s face it: Full control is only possible with manual labor, which is exactly what I’m doing.

*Awkward silence.*

Let’s get this straight, the manual labor is assigning and grouping comments? No, to this day I haven’t found the time to do even the fundamentals. Basically everything is done manually, including retrieval from the remote sources. Apologies to those hoping for an open-sourced miracle.

Needless to say, this does not scale well (or at all), but for now I keep it this way.