If not React, then what?

The loading spinner is specifically for people with shitty internet connections when loading dynamic data after the initial page load. And you're completely misunderstanding practically everything I wrote and replacing what I wrote with your assumptions. Go ahead, it's the internet, bash away all you want. But I know what I did, I know it works, and I know it's not janky at all - it's your assumptions that are wrong. The advice is good, your understanding of it is not. You don't need to reply, I won't be trying to explain any of this any further just so you can misunderstand everything I wrote, again.

React isn’t that special. You can do a react-like design in many frameworks, and in fact you can even do it with vanilla web components. The code ends up a bit more verbose and ugly, but it still has that o(n) core design. To give an idea, here’s a video I made where I port react’s tic tac toe example to vanilla web code.

https://youtu.be/bhvNvQA2oqA?si=bJYZYAU8uueb-6ST

And here’s a more advanced example that preserves input field focus and uses a context: https://github.com/jsebrech/vanilla-context-and-reducer

> As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM.

I'm curious, why?

I wouldn't call it a win. Web UIs plateaued about 10-15 years ago. It was never the state of the art in what is possible with user interfaces; it always was a huge compromise between having something that feels vaguely responsive shoehorned into a platform (browsers) not really designed for being a platform for implementing UIs. Mediocrity is the norm on the web. And react is just the gold standard for shoveling that shit out. It's not good, or great, or nice, etc. It's just that the rest is just more of the same level of mediocrity.

My feeling is that the core issues were never really addressed. Javascript was utter shit 25 years ago and it still is. CSS was an inflexible complex mess. And it still is. And the browser's DOM tree was more or less an accident that resulted from a brief industry wide obsession with things like XML. Hacking UI frameworks on top of that is basically what most frameworks do. But it's just not a very good basis for any of that. Design by committee stuff. All of it. The worst is that there's a lot of good UI out there on other platforms.

The web was awkward and painful 25 years ago and it has gotten a bit better but actually not a whole lot. There's nothing pretty about it. Or state of the art (not even close). It's just a lot of mediocrity and a culture of people confusing this mediocrity with "apparently this is how it's done" and not even questioning it anymore. It was easier to do some things with Flash twenty years ago than it is with web technologies today. People have stopped bothering to attempt to even do a lot of these things. Just not worth the pain. And mediocre is good enough. Slap a drop shadow on it and call it a day. Maybe a cheesy css transition here and there.

I love brutalist websites like HN calling bullshit on this crap. Dang and his friends don't even attempt to dress it up. It's orange! Forever! Enjoy. It looked dated ten years ago, the same it does now. But it's also a major news website running circles around most of its competition. At best they might weak 1 CSS color around Christmas or so from orange to red. That's about the extent of "web design" that happens on this website. It doesn't need it. It would be just window dressing.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds.

This is not my experience on real react sites. Loading the pages on mobile (say 4G) takes seconds to load with a partially rendered page which is slowly constructed. Loading the equivalent pages in HTML rendered server side would reliably be under 100ms (excluding assets). This is somewhat disguised by better connections and large images taking up, but all that js and json does have a cost.

You're probably trying to talk about the overhead of the framework, but what is the true overhead of a framework which encourages you to introduce bloat and create a separate component file and sometimes a separate network connection for every single component on your web page?

Here is a real case study with comparison of approaches from this author: https://infrequently.org/2024/08/object-lesson/

>The second reason the author says is that it’s based on a legacy eventing system which supports IE.

There are lots of horrible bits of react which are based on solving problems which aren't really a problem on the web any more - from manipulating the dom (pretty easy without react) to dealing with IE polyfills, and lots of bits that you really don't need the client to concern itself with (i.e. routing code). You may not care about that code but you are importing it and forcing your users to download it. It all adds to overhead.

There are also a ton of other points in the article which you've elided, which go into the multiple failings of React as a tool, and primary among them is that it encourages you to use react and only react, the ultimate in lock-in.

> Finally, the author doesn’t actually give a prescription as to what to use instead of React.

You want them to choose one framework instead of react, they're explicitly rejecting that choice and saying you don't have to become a follower of react or any other religion, instead they're advocating choosing tools based on the evidence they have presented, so they are IMO presenting a clear choice:

Server side rendering with a bit of js as required to load dynamic data

React or similar frameworks which try to push everything to the client