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.
Their account was restored in 10 / 19 minutes! It just took 4-6 hours to get everything fully healthy. I look forward to seeing the google response to this hopefully.
May 19, 22:10 UTC - Our automated monitoring detected API health check failures and paged our on-calls, who started investigating the issue.
May 19, 22:11 UTC - Dashboard returning 503 errors. Users unable to log in.
May 19, 22:19 UTC - Root cause identified: Google Cloud Platform has suspended Railway's production account.
May 19, 22:22 UTC - P0 ticket filed with Google Cloud. Railway's GCP account manager engaged directly.
May 19, 22:29 UTC - Incident declared.
May 19, 22:29 UTC - GCP account access restored. All compute instances remained stopped and persistent disks inaccessible.
The timestamp inconsistency teraflop points out is
interesting — but the bigger takeaway for me is that
Railway's own automated API health checks caught the
failure at 22:10, a full 10 minutes before the root
cause was identified.
That's external dependency monitoring working exactly
as it should. Most teams only monitor their own
infrastructure. When a cloud provider, payment gateway,
or third-party API fails — your own dashboards show
green while users see failures.
The lesson isn't specific to GCP — it's that monitoring
what you depend on but don't control is just as
important as monitoring what you own.
100% agree, I've seen on Twitter and HN small players facing similar issues with no recourse and response from Google. I don't know what kind of place they are trying to build there.
They got TK to woo the enterprise customers who were forced to be hostage to OCI. But it seems they are still doing opposite of hostage here.
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.
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.
> 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.
Nor is fetch a good client-side API either; you want progress indicators, on both upload and download. Fetch is a poor API all-round.
You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.
If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].
Browser fetch can lean on the fact that the runtime environment has hard limits per tab and the user will just close the tab if things get weird. on the server you're right
I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official
> 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.
Yes, though again, the language around registration gets really messy. Here's a great article (with a great title!) from the Journal of Singing by Christian T. Herbst "Registers—The Snake Pit of Voice Pedagogy": https://www.nats.org/_Library/JOS_On_Point/JOS-077-02-2020-1...
One relevant excerpt before the article goes into several pages discussing M11 vs M2:
> These four laryngeal mechanisms are typically termed as: vocal fry (M0, pulse
register); chest voice (M1, modal register); falsetto (M2, head voice?); and whistle register (M3).
Another article by Dr. Ingo Titze (an icon in the field of voice science and basically the father of SOVTs) about the debated "mix" register, starts this way:
> One is called chest voice, full voice, or modal voice, which is described by
a vibratory mechanism that some have labeled M1. Acoustically, harmonic energy above the fundamental dominates the sound spectrum in this register. The other anchor is called falsetto or light head voice, which is described by a
vibratory mechanism labeled M2.
It is indeed part of the standard. It says "Within a structure object, the non-bit-field members and the units in which bit-fields reside have
addresses that increase in the order in which they are declared"[1] which doesn't allow implementations to reorder fields, at least according to my understanding.
Complex for humans: I can learn a new programming language in an afternoon and be reasonably productive in it within a week or two. I wish I could say the same for natural languages.
Complex for computers: We’ve had good compilers since the 50s. Satisfactory language models are less than five years old.
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.
reply