I used up all my free time points last month experimenting with a Guile Scheme webserver. Then I discovered ZelphirKaltstahl/guile-examples… Haunt is also an interesting static site generator.

When making hugo themes, it’s probably better defaulting to absURL and relURL over baseURL for links. It avoids most breakage on links that depend on a base and more easily allows multilingual support with absLangURL.

However realistically (for anything), interpretations of file, directory/, absoluteness, and relativity are varied. Testing artifacts for ≈ 100% internal/self linking consistency, under different conditions, and after every code change is better time spent debugging. Sub directories are exceptional cases… even now some of my links are broken except that my web server automatically fixes common mistakes (:

The Chrome experimental recorder tool has been around for a long while. I thought it was still mostly wip but I got schooled and apparently, this is a more faster way to jump–start a puppeteer script/test:

Which browser engine “paints” HTML the smartest on my device? In the clip below; Surf substitutes for Safari and Chromium for Chrome. My blog is the testee since there’s guaranteed cache control and jitter.

Surf and by extension Safari (or any Webkit–based browser) wins imo. Webkit feels smooth (sneakily, too smooth). It’s probably partly why Safari on macOS/iOS feels so fast. Chrome (not Chromium) is almost on par or so I’ve been told. Not exactly web dev but interesting huh?

Profiling is the nice, cozy, and lazy way to efficiency. There’s something neat about avoiding optimization and having the numbers to prove it relative to an initial baseline. In PHP there’s Xdebug and KCachegrind and I recently saw php-spx in my feeds. A profiler in any language environment with snapshots of performance over time is just — well nice. The terribad situation is not understanding exactly how something became slow. It might be too late then.

Messing around with a statically generated site can easily lead into a web/browser spec rabbit hole. And… that’s when I remember exactly why everything ends up written outside the browser’s framework into a js framework. I think Firefox is still the only browser that allows easily setting image fallback styling completely with just CSS?

Hyperscript Tagged Markup (htm) is pretty good. It uses tagged templates.

The Enhance Framework looks compelling. Personally, web components and more particularly the shadow DOM are not very appealing but… the template structure looks clean for drawing up components/layouts super fast while still being primitive enough to not lose transposability between different environments.

It seems like there’s an uptick in discussions online around web components but maybe that’s just the typical developer marketing/advocating. Web components have been around for a bit.

I’ve since realized that Hugo’s architecture provides a variety of template optimization strategies. Hugo builds pages concurrently, so it might be hard to see on a modern device but before partialCaches or module mount trickery — there’s still the implicit complexity of the output/lookup model.

Generally the complexity cost of the default output formats are: page > term > taxonomy > section > home. Keeping expensive calls inside a section and/or a home template is usually optimal. i/o and maybe memory should be the only problems with lots of pages.

Hugo is a gateway for discovering neat golang libraries. Version 0.104.0 introduced a color extraction method that has lots of use–cases. An easy one is to generate basic image gradient placeholders. The browser has its own deferred/lazy loading logic so fancy image gradients (on a static site) require only a few lines of pre–generated CSS styles.