Stefan Judis

> would it be feasible to include the compression dictionary along w/ the data

In theoretical terms (in particular Kolmogorov-complexity perspective), I believe the inclusion of a dictionary wouldn't help, it would strictly increase size. It can help (specially from a Shannon information perspective) if the compression is too computationally demanding to build the data model (which is kind of what all compressors do); but it almost certainly doesn't help in the case of something as small as an URL. But then it's possible to just pack a common compressor with the website (and just refer to it with a version code).

I think the web in general would benefit greatly from some kind of standard compression libraries. Compression tends to have a significant cold start cost to work well, if that were mitigated certainly something like an url could be far shorter.

I believe HTTP2 has header compression (RFC 7541)[1] with 'static tables', which seems to be a form of dictionary, but surprisingly to me no html compression with such shared dictionaries. There is caching libraries (unfortunately cross-domain caching seems to be deprecated[2] due to security concerns) I believe which helps in other ways, but I think a true dictionary-style compressor would bring huge bandwidth savings.

Major web entities should get together to develop those standard dictionaries (and which algorithms to use them with), so they are reasonably fair for everyone (maybe even language specific dictionaries…

i mean, you forgot to change the structure of this blog post when you ripped it off: https://www.stefanjudis.com/today-i-learned/prevent-npm-install-for-not-supported-node-js-versions/ -- you also didn't change the title sufficiently, so if i search your title in google, i get stefan's post right under yours.

i also see that on your post just prior, you use an image that's stolen from this article: https://appuals.com/how-to-kill-process-on-port/

and of course, for that `kill-port` article here is the source you rewrote, which i found syndicated in a few different places:
- https://softbranchdevelopers.com/terminate-process-on-a-port-from-command-line/

leaving aside that articles like these are basically just verbose refactors of official documentation, you could at least put in some effort. it's fine if you aren't original, but if you're just changing the phrasing of other people's articles and publishing that as your own work, for something as simple as `-prefers-color-scheme`, you're in the wrong field

> just stick your content on a static host and you're done

1 (relatively small) advantage is not needing to control the server, just the domain. The server then polls IPNS and updates things with the latest stuff.

2 There's the standardized (and perhaps more meaningful) cache busting aspect for assets. i.e. the IPFS Companion browser extension takes all /ipfs/<CID>/filename.ext urls and sends them from the local datastore instead of making requests. This way, assets aren't requested from a remote each time when they're the same on multiple websites. This helps since CDN's don't use common caches anymore. Though, it might come with the same privacy risks.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/

> it's hard to embed and resource-hungry, which hampers adoption

yes.

So, I absolutely love htmx, and this new version offers some incremental improvements that make things even better (unless you were using WebSockets or server-sent events, I guess, but the plug-in model doesn't look too bad?).

Unlike all-or-nothing approaches like React, htmx allows you to add just the right amount of partial updates to your web app, using just the technologies that were already there to begin with. I realize that this approach doesn't appeal to everyone, but being able to map simple requests to simple responses was an absolute life-saver for my projects many times over.

Migrating to a truly-truly minimalist approach (see: https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alternative/) is still on my to-do list, but for now, I'm quite happy with the htmx status quo.

There are multiple standards.
https://www.ecma-international.org/publications/standards/Ecma-404.htm
Is more relaxed.

>The JSON syntax does not impose any restrictions on
the strings used as names, does not require that name strings be unique, and does not assign any
significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by
JSON processors or in specifications defining specific uses of JSON for data interchange.

Also it's pretty clear that the keys must have an order going over the wire. And JavaScript objects (which aren't unrelated to JSON have an order now) https://www.stefanjudis.com/today-i-learned/property-order-is-predictable-in-javascript-objects-since-es2015/

It's impressive how well the minimap works for bigger articles, I clicked around randomly and ended up at https://www.stefanjudis.com/notes/should-responsive-images-work-with-container-queries/ and the minimap feels slightly magical since it appears instantly and updates synchronously if I do things like select text.

It feels kind of disappointing that I can't interact with it to scroll around like in i.e. Sublime Text, but I imagine that's a little harder to do as the author of a website. It's still very cool to me that you can do something like this on the web, and I wonder how much work it would be to support this complex CSS feature in Chrome or Safari.