dynode is now static

Authored: 04/04/2023 17:35

The latest update to dynode includes a move away from MDwiki, the static site generator I was using from dynode’s inception in 2018 to render its pages via markdown. There are several reasons for this, as follows:

The new markup has been generated with pandoc (more on the process of creating the IPFS object here), and placed into separate static HTML files for each page. This method likewise confers its own benefits:

I was first introduced to MDwiki by a colleague from a mutual project as a convenient means of generating documentation without the complications of building source code trees like with typical documentation generators. When it occurred to me that these pages could be added to IPFS and loaded through public gateways quickly and with ease, the broader implications for online publishing (especially as it pertained to IPFS) became clear, and so I created an infographic explaining a method for creating these sites (alas, I was apparently beaten to it by several months by a Chinese dev), followed by dynode, the proof-of-concept.

Since then the site has served (and will continue to serve) as a sandbox of sorts for my forays into the matter of self-publishing. Attendant to that is a general philosophy (or set of principles) on the matter of publishing that is perhaps best expressed through the form and content of the site itself.

To that end, the latest update was intended to demonstrate advantages mostly concerning the goals of simplicity, minimalism, and efficiency - not simply for their own sake, but for the fact that these things ultimately determine real-world accessibility for users who do not have infinite resources to expend.

For most fibre- or 4G-connected users in developed countries with reasonably-priced and reasonably-performing devices, for example, the end result of the tremendous bloat of typical Web design can be absorbed with relatively few problems. If even minor increases in latency are introduced here however, then every 14kB loaded thus becomes critical. Likewise, resource usage generated by unnecessary features or styles within services catering to thin clients are less easily dealt with by lower-end computers. These problems yet compound for everyone with each additional tab, page, or service one is attempting to load.

With that in mind, the new design attempts to emulate much of the visual elements of the MDwiki theme I was using in simpler ways (e.g. sticky headers), with some minor differences. The background-foreground tones have been inverted for example, to make pages far easier on the eyes. Hyperlinks have also been made a muted green, which, as it happens, was the original colour used during early WWW testing. To complement this, a ::selection selector is used to make the backgrounds for highlights green too.

There are also a couple of hacks and newer elements of CSS I have implemented, usually to achieve certain functionality in lieu of using scripts - for example, a semi-successful attempt to imitate the on-click image expansion of Gazelle for images without links, which, for wider images, don’t quite hold their aspect ratios. This WIP aside, I have retained the Lora font from MDwiki, but am using it in variable font form, to keep the necessary files down to 2 (standard and italic), and to make it simpler to switch between them.

One may understandably submit that these simple inclusions violate the very ideals that were just raised. To this are some pertinent notes: firstly, any worry of incompatibility or deprecation in the case of variable fonts is rather small, with no less than 95% of browsers supporting the feature (merely 1% fewer than the general support for system fonts). The same may be said of the :focus selector, that, along with a tabindex value of -1 for <img> tags without links, I use to achieve image expansion - where support lies at almost 97%.

Most importantly, these additions present nought but embellishment for pages that would otherwise still function equally well. For the vast majority of users with browsers that can support these functions, some extra kilobytes loaded for aesthetics is a worthwhile tradeoff. For text browsers, this is irrelevant anyway, as they probably won’t be loading images or styles, and the sensible, minimal page design will look almost identical regardless (and for that matter, even the raw HTML is more readable than many sites offer today).

Crucially, all of the content will still load and will still work for all users, in spite of their individual set-up. None of the text is being placed behind the barrier of arbitrary and superfluous code execution, no image is prevented from being seen. As what will likely be the most advanced elements of styling I will implement (and the closest to an exception for these ‘static-only’ pages), I consider the use of variable fonts and image expansion a valid trade that will probably not even be felt by the tiny fraction of users who can load images but not years-old styling functions - and the same argument could be made for styling support in general.

To ascertain some kind of measure of speed improvement over MDwiki, I also conducted some tests.

While they may not have passed your average peer reviewer, I did try to maintain something approximating lab conditions when collecting the values plotted below. The process itself went as follows:

I calculated mean values for each page load, on each gateway, and used them to produce the charts below:

Before interpreting, there are a few notes to be made:

Now, on to the takeaways.

First, the most evident and expected result is that of the advantages of the static pages. On half of the 6 tests where the pages could be loaded, the static pages loaded more quickly than the MDwiki equivalent, but for the other 3 tests, the MDwiki pages would not display at all. During each of the tests where the static results were better, they were all by extreme margins, which was not the case the other way around.

Second, it is quite clear that the performance of the Protocol Labs gateway leaves much to be desired. 2/3 of the times that MDwiki had won out, it was on the ipfs.io gateway. While cached loads were adequate, it performed poorly on fresh loads. I was intending to move the HTTP domain back to PL, but in light of this, I will be keeping it, for now, on Cloudflare’s (and linking via dweb.link, which also seems to be run by PL).

Also, for all of the static loads, the Pinata and Cloudflare gateways usually downloaded the same amount of data as one another. The PL gateway however, often downloaded an extra 100 kB when compared with the others - most obvious here within the index page, as that is 2/3rds of the entire page. Upon closer inspection, the PL gateway appears to be downloading the full standard Lora font file (209 kB in total), while the others fetch half of that (the non-bolded half?). Not sure how this is done, but interesting nonetheless.

Finally, the arcane JS constructions of MDwiki are unavoidable and even cascade into one being entirely unable to load the object - and it makes me wonder how many times this has happened over the years of people trying to access the site. It serves as a lesson in itself regarding the trading of bloat for convenience.

While I still consider the MDwiki guide to be a fine way of quickly spinning up an avenue for Internet publishing for those without even the requisite HTML knowledge, there are indeed better options when usability and readability for a wide range of users is desired. As always, dynode remains a primary ground for testing such experiments, and ultimately, this is but one redesign of perhaps many in the future.

https://www.eff.org/cyberspace-independence · Markdown edited in vim · compiled with pandoc · hosted via IPFS · Mirrors: HTTP | IPFS