Its now 2020, and I quickly made another jquery plugin. “what, why? Do I even internet?"
I started this project in 2009, when jQuery was a reasonable abstraction layer; I didn't have much JS experience at the time, although I had been a professional developer for over five years. Professionally I used jQuery between 2011 and 2013, maybe 2014. In terms of deliver “reliable business solutions” for forms, or simple and mostly static websites, jQuery isn't bad. I don't have much interest in replacing every JS thing on here with a newer more fashionable one.
Since 2014 most people are migrating away from a toolkit designed to suppress browser in-compatibilities. If I was starting this set of webpages that feel like journal articles now; I would look at AlpineJS git. Note Alpine would require adding features such as a AJAJ/AJAX module separately.
The reason for this intro is “what type of JS support is useful for sites that behave like journal articles”. To a lesser extent this question also applies to blogs. In my opinion, there isn't much interaction or scripting needed. This implies that adding Angular, or React, or Vue (which I used sequentially in my last three employment projects, with more complex objectives) are massively over engineered tools to be able to present text. Please note my site has a readable font (has done since about 2012) as this assists the use-case of reading text. For comparison, none of the paid projects in the same timespan, which are using bigger JS toolkits; had non-default fonts.


  • To make 'similar content' articles more conspicuous from an article;
  • To make it easier to browse this site as a unit;
  • To be very clear/ easy to understand and use;
  • To reduce this sites the dependency on index pages (which as an interaction, feels strongly 1990s/ “web v1”);


It is reasonable to ask “why is this implemented in JS, rather than your serverside language?". The answer is that I would like my current article format to work with static sites. It is not practical to statically build “the next X articles on the same topic” as a pre-computed list on each article. Or if I do do that; to be able to update it with new content. Secondly, if you look at quite a few blog sites; they also use a separate “related content” API; partially for syndication. If this has been published as a design pattern, I don't know what it is called. UPDATE: having written that text and feature; it now occurs to me I can keep the separate file (my requirement), and use some sort of SSI technology (on this site, probably a iceline v2 file include) to do the merging. This may be a tad faster to render; its probably not valuable to optimise that point. I have wasted about 10min using a “normal process” ~ AJAJ ~ to get the data to the client. The process I did build is more re-useable.

As far as I observe, tag clouds are now passé (and have been for some time). The related content, for example on ars technica e.g. 1 seems to solve the same objective. It is intentional to allow an article to appear in more than one group. Likewise its not actually required that all articles in a group are owned by me.

I am not sure whether it is worth adding a new git project for this; I suppose the least wasted effort solution is to add it to the jquery-ob project. Obviously the new feature is very tightly integrated into the CMS.

WARNING: Making this feature meant I have reviewed nearly all of my content; I have improved English; I have added metadata, descriptions mostly; I have added contentGroup attribs. This means the last edit date is now fairly pointless. I have looked into the “file create date”; on my desktop, this is meaningless; as I have changed machine 3-4 times since 2009 when I started this website. I have looked at the “git creation date”; unfortunately I have changed software version control more than once too. I could try to get the data out of google; but that would be a noticeable RnD project for me. As such old articles are now listing march 2015 as the creation date, even though that under ages them by some distance.

As most search engine bots support JS 2 3 4, there is little value in a static article index page. If a historical tech approach is needed, I have a dynamic RSS list and a dynamic “site map” resource; which are both flat indexes; to be inclusive for older technology. My home page is an index 'wearing a fancy hat'; I guess it needs to stay, to support users who actually type the URL in. If you land on the site after a search; you are unlikely to see the home page at all.

I intend to iterate the UI; to minimise space, and supply a lot of information efficiently. It is minor-ly worth noting that the extra tool-tip (operated with CSS) to tell you about the links is fiddly; and will need careful testing. I have iterated the English; clearly this is a group/directory structure, but I don't think 'group' needs to be an important term in the display text.
I see there are two groups of users who need the feature:

  • Random people who wandered in from a SERPs; but use keywords differently to me (as different location/culture/language). I think this group of people are likely to just hit “back”, as that is what I would do.
  • People who have already been to the site; but went from a bookmark or similar, and are on the wrong page. The adjacent articles feature may help these people.

I have added an extra option to the fixed page menu to assist people who think its worth a few clicks to find their objective.

Testing on this feature is not very traditional. The meta data has a large impact on the usefulness and the readability of the feature. The code committed to git has unit tests; but I am manually testing every single step; and adjusting the articles. I observe a similar process in other meta data projects; which makes them expensive.

Technically this feature is:

  • time spent thinking about how to group the articles
  • a lot of time improving meta data in each article, as I am now using it more
  • UPDATE: today I added even more time here
  • a procedure that each group has a meta JSON resource to list the articles in the group
  • an extension to my biblio extraction tool; to build meta data indexes for the articles in the group
  • a [not released] script to help me aggregate the articles
  • a jquery plugin
  • a small revision to the 'reach' page template to include the extra HTML/JS
  • a small revision to my asset build script to include the new JS file
  • currently the CSS is in my main site CSS file; I ought to extract this for the separate project.
  • I noted previously that as I was editing my content; the last edit date isn't as useful as it should be (now I have touched nearly every article making this feature). I have built a way to extract the article create date from git

The biggest time spends where updating old content (quelle surprise) and making a solution to tooltips popping up and hiding the buttons they are for.

Some similar articles in worklog