{title}

Pagespeed and "pushrouter"

For the past couple of weeks I've been working long hours on a rather time/energy-consuming project at work. To keep some sense of balance, I've filled some of my free time with thinking up improvements for FinderUI1 and experimenting with implementations using my personal website as a guinea pig.2 Ultimately, getting my site to "a good place" is the "chore" I must finish before continuing to work on some Rust stuff (and messing with the basics of bootloaders). Regarding recent work on FinderUI, my learnings/ganders include:

  1. Understanding how to properly balance generalized functionality vs. specificity when designing a library
  2. Making boilerplate useful but also not-too-opinionated, and balancing the presence of boilerplate with optimization/flexibility (why would the user need "x"?)3
  3. The future of routing, especially considering S(ingle) P(age) A(pplication)s, the HTML5 History API, and programmatic navigation in frameworks like React and Next.js
  4. Optimizing pagespeed with PageSpeed Insights

FinderUI is interesting because is provides a simple way to conceptualize the structure of views on a web app as a file tree, specifically by emulating a file explorer (like Finder on MacOS, or if this was used to render React components). The FinderUI component receives data (a JS object) and simply renders whatever it's instructed to depending on what "node path" is "activated". What makes this interesting for web app development is that changing views is as simple as changing the "activated node path" in FinderUI. The moment a new path is invoked, the component activates the "display node" (view) at the end of the given "node path", resulting in "navigation" at the speed of JS. Effectively, this isn't much different than any other SPA library which fakes navigation by changing application state and fudging the location and document title.. but FinderUI makes configuring this navigation as easy and flexible as writing up a JS object and a few components to serve as "display nodes".

I've been making FinderUI with my personal site in mind (how cool would it be to have a website that acts like a file explorer, I thought), but now I'm wondering whether it provides value for general-purpose.

Mistakes are the cost of learning

It's crossed my mind that I might just be re-packaging old ideas (basically janky React Router) and thinking that I'm doing something more original, but it's all part of the learning process. Something that aroused this suspicion in me (of being unoriginal and over-generalizing FinderUI) was my addition of a "pushrouter" (inspired by this ) to the component.. which has a lot to do with items "1" and "3" on the list several sentences back. (1: why include a pushrouter when Next.js includes their <Link> component? 3: self-explanatory) (FYI: "pushrouter" refers to programmatic navigation via some functions wrapping the HTML History API) Why add a first-party pushrouter to the component when React and Next already have much better versions of the same thing?

Well, one answer is that this pushrouter is very light and fast. While it's not as robust as React router or Next.js' system (especially when you hit the "back" button, it's far fewer lines of code and does a fairly decent bare minimum. And, considering how barebones my site is, my little personal pushrouter still achieves instantaneous navigation (which is, I imagine, why programmatic navigation came about). Some views load themselves asynchronously (via the power of React Async), but the navigation itself is a snap. Considering light, minimal, lightning-fast websites are in vogue these days, this is always a plus. (Not to mention that Next.js does an okay job of covering "back" button clicks as part of their built-in "filesystem" routing feature.)

For a few minutes this afternoon I'll spend some time looking into more ways to speed up the site according to Lighthouse/PageSpeed Insights (image filesizes and next-gen formats like WebP).. and then it's "chore done" and on to Rust stuff (...and bootloaders maybe too) before Monday comes and my focus returns to work.

  1. 04/11/2020 - Now called StructUI and archived, though I have plans to make a fun vanilla JS thingy in the same vein 
  2. 04/11/2020 - This post refers to my *old* personal website 
  3. This has more to do with what boilerplate CSS to ship with the FinderUI package.. which leads to more internal discussion about whether FinderUI should even try to be anything more than a "decoration" library for silly people who want websites to look like file explorers