Echo JS 0.11.0

Nice writeup... I would point out that these kinds of tests can be somewhat costly and very time consuming in terms of the time they take to run.

Depending on your workflows, you may want them earlier or later in your lifecycle.

Another point worth mentioning, is that you will want to consider device/viewport configurations as well.  I use my phone (Android) with Text Accessibility cranked to max because of visibility issues that glasses won't correct.  I cannot tell you how many times I will face a mobile dialog or other content that is completely unusable/broken for me.  The other issue is having things forced too small, though the PS's triple-tap zoom helps significantly there.

Of course the Accessibility rabbit hole is an adjacent topic beyond the minimum viewport testing.

Two books that still hold a lot of value are "High Performance Websites" and "Even Faster Websites" both by Steven Souders who works(ed) on web performance at Google.

There are a lot of tidbits like this that can add up a lot.

Personally, I tend to deploy/configure most of the applications that I work on such that all requests are to a single origin that may reverse-proxy to differing systems/applications on the backend.  For example, I almost always separate static resources, /api and /auth from each other.

Gotta love evergreen browsers... this was added as part of ES2022 and works in most browsers.  Though Safari doesn't seem to log the cause by default.  You may also need to add additional logic to output to external loggers as well.

Noce feature to have...  I'll usually add a statusCode and other properties into my HTTP handler stack in TS in order to do custom error handling for short circuit responses.

They're both going to be 9 characters (base 32 or base 36), also It's a bit pedantic but base32 is more broadly supported, and part of the same standard as base64.

https://www.rfc-editor.org/rfc/rfc4648#section-6

Mostly to save the space... I'm also using the YYYYMMDDhhmmss value as an integer so converting it back is slightly easier to visualize...  I had already written and implemented the logic before I'd considered Math.floor(now/1000).toString(32) which would only be 7 chars.

I'm using grate for database migrations and just wanting to capture versioning that matches the project(s)... the release version is tagged to the release number, but every merge/push into master gets deployed to a shared dev db.... I wanted to better track those deployments... I'm also now adding a link to the repo url for the commit that was deployed.

In the end, it's mostly for uniqueness, and the githash is probably more valuable than the timestamp, I just wanted it there.

The biggest down side is GPLv3... which won't work if someone wants to use it in a GPL+Commercial product downstream.  I understand the desire to monetize this component library, but it definitely precludes it for a lot of backed project usage.

Not sure I could even suggest a good alternative depending on the desired usage/outcome.

That's cool... and I literally meant Redux as a state machine on the server, have considered doing this for shared state app, and then sending JSON diffs to the client via WS, then client events likewise bubble to server as a round trip.

This would be for a shared learning environment/simulation... though could probably work for a game where some level of lag is tolerable.  Such as a shared board or card game, etc.

Cool, made an issue/suggestion to tweak holidays slighrly.

Could definitely see this as part of a larger application that included calendar management, or even a reduced app that worked in concert with a CalDAV service.

Interesting, but only part of a solution.  Aside: what's up with that version number?

I've given a lot of thought to needs that this would fit, and I've mostly considered the use of Redux, or something closer to it.  The other part of the issue is what to do with that data, this is where you will likely either be replicating state changes/diffs across something like websocket channels or you will wrap that into something like Apollo for GraphQL updates similarly.

In any case, this really feels like only a small part of what you might need for a solution, and really need to consider how this fits and if it really suits the needs of an application/solution whole.

You could also maybe apply a css filter/transition for mousedown-up to adjust the color slightly towards white/black depending on the mode.