I write a blogpost twice a year and then spend 4 hours fixing my handcrafted blog engine. It's healthy to stay in the loop regarding the latest Vite, Typescript and React bugs and inconsistencies I guess.

Anyway, I explained a cool pattern with Rust traits:
https://lbfalvy.com/blog/...

HTML and CSS validation could be improved, but generally nice.

Though one of the points why I rolled my own SSG is so that I don't run into such tool chain issues.

@Fast-Nop
This was a crackpot experiment, I started a much more ambitious and better thought out SSG framework to replace it but got distracted. I add features or change things every time I publish something and it takes the evolving demand very well all things considered, it would just pay off more if I posted more often so that the part about fixing NPM packages wouldn't happen every single time.

Automatic highlighting is brand new in this release and accordingly kinda bad. The Orchid highlighter in earlier articles is a handmade parser written in Typescript, an experience I don't recommend.

There was a good talk I saw on building a "knowledge garden" or something along those lines.

It's lovely to see devs writing about stuff they find interesting and want to share - it'll pay off for your resume and technical writing skills

@lorentz I'd say it's not an issue with your blogging frequency, but with the brittle NPM ecosystem itself.

Then again, if the actual purpose of the blog were blogging, then it wouldn't need React or even any JS at all. Plus that pure HTML/CSS wouldn't sporadically show "failed to load component". ^^

(Not only in Chromium, but also FF, and it works after reload, and it's erratic. Btw., "Blug"? Wordplay on blog and bug?)

@Fast-Nop Oh that's a nasty bug, I fixed it like 3 times already. I only ever make SPAs because I hate the default "flashbang" transition effect of browsers, but this means that lazy loading for articles has to be procedural.

I have a clever component for lazy-loading anything, but it's pretty old code from when I was less rigorous and I think it violates some React rules.

@lorentz What flashbang transition? Do you mean FOUC, flash of unstyled content?

@lorentz Also, disregarding KISS just introduces needless complexity which causes unnecessary maintenance effort as well as bugs. Browsers don't need SPAs to read documents, that's what the WWW was made for.

@Fast-Nop The WWW was made by a bunch of people with conflicting agendas, and far too little negotiation. Some parts were made five times, some parts were never made, some parts technically exist but because other parts work differently or are missing altogether they turn out not to be very useful, some parts are only supported by Chrome, and there are even a few things that only exist because Chrome and Firefox had the same bug so they decided to codify it.

This blog could have been simpler, but not because the WWW already does what I want. It could've been simpler because there are browser features that I could co-opt to realize more of what I want with relatively few tradeoffs, except perhaps on Safari which is intentionally broken to promote the app store.

@Fast-Nop I'm talking about the FOW (flash of whatever) between the moment the user clicks on a link and the moment all content was loaded, all synchronous JavaScript executed and all CSS applied and the content of the screen is beholden to standards. Some browsers have a flash of white, some don't, some have tools to remove it. I don't want to engage with that crap if I don't have to.

@lorentz The WWW was made for reading documents that link to other documents. That's what the very first browser in the early 1990s did, and that's functionally all you need for a blog.

As for a reload flash, the usual number one reason is because you access render dependent parts of the DOM in JS before it is rendered, forcing the browser to render anyway. Injecting stylesheets via JS may also run into that problem.

If you don't try to re-implement native browser functionality in JS, but leverage CSS with static head includes which is render-blocking by design, then you shouldn't have that problem.

@Fast-Nop The flashbang transition is the main guide I use to identify SSR-only websites while browsing as a user because it's literally always there. Especially when the website doesn't use any JS, in those cases it's often longer too because the browser has to load a gigantic single stylesheet for every page full of untraceable overrides that no one will ever take apart into reasonable specialized files.

Being a document reader was about the only thing early web browsers had in common, alongside simple cases of HTTP. What a document is, how it's written, what it can contain and what the user can do with it has always been and still is a point of contention. I restrict myself to the parts that work more or less the same everywhere.

@lorentz There is no reason for gigantic stylesheets. More than 32k (minified, before gzip) seems excessive, and that's already generous.

In particular, you cache the stylesheet(s) client-side so that the subsequent page doesn't have to load any styles anyway.

The solution to slow page changes is not adding more bloat, but to remove the bloat and use proper caching.

@Fast-Nop those are great tips for making the flash shorter, but what if we could avoid it altogether by keeping the part of the document that doesn't change on screen?

@lorentz The point is: if you do that properly, you don't have a flash to begin with. Don't mess it up, then you don't have to "fix" it.

@Fast-Nop But you do, it's just short. The very first website I made with PHP and CSS that had just a couple paragraphs and a 10 line CSS file had a flash. If there's a way to reload a page without it, that has to involve some explicit commands addressed to the browser. I've never ever seen a website that didn't use client-side navigation (including turbolinks) and didn't have a flash.

@lorentz Strange, I havn't seen a website that flashes and doesn't cause that via some ill-advised JS. After the click, both Chromium and FF keep showing the old page, not a flash of unstyled content.

Note that said ill-advised JS can be about something totally else, unrelated to navigation.

It's particularly visible if you implement dark mode via JS in the onload handler, that's going to give the light mode flash, then change. Doesn't happen if you instead evaluate the preferred colour scheme in CSS.

@lorentz Btw., another link aspect where your blog is broken: scroll down in a page, click an internal link, use the back button of the browser. Boom, scroll position lost.

That's what routinely happens when you ignore KISS, re-implement the browser in the browser, and then don't have the vast amounts of time you'd need to actually pull that off.

@Fast-Nop Ah, gotta add another scroll restoration trigger. Actually, I think I'd be better off turning the restored scrollable box into a component. That could be a lot cleaner.