cyco130

Almost all of the trending repos on GitHub are _about_ AI: zillion of harnesses and similar AI orchestration tools. So most of the extra efficiency gained by AI usage seems to be spent on building more AI tools and not software for end users or libraries for AIs and humans to build such software.

I think researching things that have little internet footprint is an underrated use of LLMs. Most recently, I did quite an extensive research on a card game called "king", variants of which are played in Turkey, Portugal, Brazil, Belgium, France, Russia, Italy, Poland (under the name "Kierki"), and several other countries (but seemingly not known in English speaking countries, despite the English name). It allowed me to uncover scoring patterns that tie various versions together and reconstruct its possible origins and development, however speculative.

I've heard of it, of course! And of course they're years ahead of my little hobby project.

But there's an important difference: They run on the browser via WebAssembly, the project is in Rust. Sfotty Pie is pure TypeScript, so, hopefully, easier to hack for a greater number of people. Also harder to make performant but why do we have all this CPU power if not to emulate 1.79 MHz machines using high-level languages :)

I can see where the arguments for React's alternatives like Preact, Vue, Svelte, Solid, etc. come from. All of them are better than React at least in one aspect and React's dominance is mostly due to inertia: Developers (and now LLMs) know it better and the ecosystem is richer.

But having built websites and apps since before jQuery times, I strongly disagree with manual DOM manipulation as an alternative. Declarative, component-based approach won for a reason. These frameworks allow you to tell how the UI should look based on the state and manages the transition (either via virtual DOM diffing or fine-grained reactivity) for you. DOM manipulation requires you to write some code for every single state transition (instead of every _state_). And, in practice, it becomes unmanageable very fast, and you give up, and start writing code like `element.innerHTML = ...`, causing problems with focus and event management. It's fine for small widgets, even enjoyable, but only until you need to manage a complex UI. Then, you end up with a mess of code that is hard to maintain and debug.

I know some still feel web is not the right platform for building complex UIs but that battle was lost more than two decades ago. Web is good. It comes with accessibility features (like zooming) and works everywhere. As someone with age-related farsightedness, I hate native apps that don't allow me to zoom in with a passion (which is, almost all of them). Of course I hate websites that don't allow me to zoom even more because they had to go out of their way to disable a basic browser feature. But getting decent accessibility is harder with native apps. You basically have to build everything yourself. Web gets you 90% there for free.

React might not be the best out there and might be, one day, replaced by one of the competitors or something new. But declarative, component-based UI development is not going anywhere.

And this is Railway, a big enough name to top the HN main page and presumably find someone from Google to intervene at some point. I would have zero recourse if it was some little product that I built.

tanh is a very pleasant sounding overdrive function for audio, for example.

One neat trick for TypeScript branded types is to use { "~brand": "SOME BRAND" } instead of { __brand: "SOME BRAND" }. __brand shows up at the top of the autocomplete keys where "~brand" shows at the bottom.

Axios has maxContentLength and maxBodyLength options. I would probably go with undici nowadays though (it also has maxResponseSize).

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Thanks for the articles, great sources.

> Current literature does not distinguish between head voice and falsetto.

Hmm, are you sure about this? I thought chest voice and head voice were understood to be a single register called the modal register. And falsetto was fundamentally different.