Thimble Switcher In 87 Lines, Fediverse Software Commons

I posed a question to the Fediverse asking what was the most minimal front-end framework for client-side switching between pages, and did a bunch of research, and found a bunch of "micro"-frameworks, including MithrilJS, SlingJS, Hyperapp, htm, NanoJSX, Preact, uhtml, reefjs, and htmx, which all were much smaller than React, but still overkill for what I actually was trying to do.

Then based on a suggestion from @j12i@weirder.earth, I attempted a solution in plain javascript, and was pleased to achieve a result whose user experience was to me comparable to Gatsby, in 87 lines of plain javascript.

I then added ASCII Art to the javascript file header, as well as code to set how long cached pages should last before they expire, and incorporated error-handling suggestions from the generous spontaneous code review of @forest@pixie.town, and now the total line count is 144, but still within the ballpark of the first working version.

I used git ls-files | xargs wc -l on the facebook/react repository, and found the total line count was 416,795.

Thus the total number of lines of my front-end code was greatly reduced, while maintaining 90% of the functionality that I actually was using.

The remaining 10% would be the nice way that Gatsby handles images (with a sort of smooth lazy load), and some image carousels I built on some pages of my personal website.

I'm curious if I could also replace both of these with plain javascript, and achieve functional parity
with the previous version.

Here is the old gatsby version for reference.

Some might call this bit of javascript a simple script or snippet, but in the spirit of permacomputing, and to elevating simple solutions rather than belittling them, I enjoyed giving it a name, Thimble Switcher, and thinking of it as a framework — it's just a very minimal framework, and a flexible one that could be subbed into any static website which has a <main> section on each page. It's also a framework which requires no extra build step, and which I hope will remain evergreen for many years to come.

We can check-in ten years from now and see how it went.

Permacomputing, Lichen-Markdown & Infinite Tradeoffs

A critic could say, "but Max, Thimble Switcher prefetches pages that the user might not even up visiting, how can you call this permacomputing?"

I would agree that if your site currently loads pages on-demand in the standard way, then adding this javascript snippet makes your site more complicated and resource-intensive, not less.

However, Thimble Switcher is more light-weight in multiple ways than Gatsby or React, so if you are switching from one of those tools, which internally uses quicklink for pre-fetching, then it makes the build process that supports your site, more simple and efficient.

Or perhaps someone who is deciding what tool to use feels less of a draw to use React, knowing they can have client-side page-switching without it.

More generally I see "permacomputing" as an approach, not a prescription of a specific tool or set of features which are "enough", which is always contextual and subjective. Distributing writing through using natural fibers and dyes or orally are both beautiful approaches which are more resource efficient than any website.

This was similar to the reasoning behind Lichen-Markdown, which is less minimal than the original Lichen, but could be more minimal than other options depending on what is being considered.

Permacomputing, Human Readable Code & Open Source

I appreciate that Thimble and Lichen use fewer computing resources than some alternatives, but possibly even more than that I appreciate that small code-bases can be human-readable.

Open source advocates often bring up the empowerment of being able to fork and modify open source code (the second freedom), which is not without value, but with large and complicated code bases, even a trained programmer may not be able to modify the source code without years of yak shaving, leaving the second freedom more theoretical than actual.

This is also pointed to by Bret Victor's concise one-page essay titled "Radical Decentralization, Radical Empowerment and Dynamicland":

However, for true decentralization to be possible, the
ideas and abilities must be learnable. Many modern
technologies are too complex to be learned and
practiced by communities, and are instead bound to
industrial modes of production, creating a class divide
between “developers” and “consumers”. These
complex technologies will never be decentralizable, and
any attempts to decentralize them will fail.

I don't think there is a pure binary here between "true decentralization" and "untrue": complicated open source code can still empower more groups to make changes than if it were closed-source, and complexity is itself a spectrum, but simplicity of understanding and modification is an aspect of decentralization that is often overlooked by decentralized technology advocates.

I appreciate that with just a few files, I can have a sense of what all the code does.