If not React, then what?

> but developers "fixate" on it because it matters to users

Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.

> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users

I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

> I suspect the average React app probably is slower, partly because React sites are generally newer...

This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.

> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...

Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.

Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.

Hooks are awful. They’re a faux-functional interface, accessing implicit local state, with so much magic going on behind the scenes that it’s obscene. At least in class component days it was obvious which components were stateful. Now you’ve got to remember which magic hook incantation is causing your “functional” component to improperly cache state and why. I cannot for the life of me see it as an improvement in any way other than “it looks nicer,” which aligns with the top-level parent’s point.

Anyway I think react in general is kind of terrible. I’ve worked at three places whereFE teams made a react codebase that wound up being so scary and difficult to work in that essentially no one would touch it, until it eventually got rewritten. Two of those just rewrote it in react again, hoping that whatever faddish state library would save them from themselves. At the third, they rewrote it in svelte, which went much better. At least for me as someone who only writes FE code when I have to, svelte is much more comprehensible and sensible.

I’d love to see how those new options perform these days by replicating a large tumblr blog or instagram feed. Might be a fun project.

That's exactly backwards. Without the type-safety in those memory-unsafe languages (like C++) there would be 100x more buffer overruns and other memory issues and security holes. Having the type-safety in place is literally the main thing that makes memory-unsafe languages viable.

> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed.

I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it. On the "Slow 4G" throttling setting in Chrome, the time increases to 620ms or so, which is noticeable enough for the interaction to not feel good. Our particular forms-over-data application is not typically used on mobile (there's too much data to enter), so this isn't an issue for us. It's all contextual. If it were an issue, we'd either use an SPA-like library for our forms, or we would send all the HTML to the client and use JavaScript rules to control visibility. It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.

> A server-side rendering framework will probably have a nice loading state... Once you go slightly off the beaten path... it becomes harder and harder

Indeed, this is effectively built in to Turbo. There's nothing special about it, you add CSS rules (turbo adds and removes classes). That'd apply to image buttons or anything else you want to throw at it. You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.

If a person started their career doing React and is still doing React, that person would have certain beliefs about things that wouldn't be true. I get the impression that most people I'm engaging with here haven't actually done what we're doing but they are somehow convinced it cannot work or that our use case (line of business forms over data) is so special that it can't possibly apply to anyone else.

> Then you've got another language with its own syntax that you're learning

Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.

> Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that...

Got it. It was somewhat flippant, I admit that. They probably know the first thing, but the concerns you're raising about tags and escaping and that sort of thing honestly somewhat reinforce my flippant assertion. If those are the things we are concerned about our developers having to know then I wouldn't want them anywhere near anything our users would touch. I think we may be used to working with different calibers of developers. I get that they're all over the map now, so this is just a another contextual difference most likely.

> ...studying the intricacies of HTML...

It's not sanskrit. I'm rather confounded by the FUD around HTML here.

> It doesn't though.

Ok. I've done it, so I know exactly what it takes, at least in the 4 or 5 different apps I built with various versions of React and friends. I also know that aside from the fastest machines on the fastest networks, there's not much you can do aside from server rendering to address the first paint issue/LCP issue. But yes, once you have the initial JS bundle, the rest of the site is generally faster. By the way, one of our 30 or so web apps we have composed into a single application with nginx/SSI still uses React. LCP is 1.2s on my M4 Max and on a page with slightly more data that doesn't have React, the LCP is 0.7s. Yes, the bundle is optimized. These aren't awful numbers at all, but I'm on the fastest machine there is pretty much. There's no loading shimmer stuff like AirBNB does. Speaking of user experience, that stuff is absolute garbage and I can't wait until folks realize it. Of course, they'd have to embrace server-side rendering though... :)

Just to be reiterate: I think there are plenty of good use cases for React like libraries/frameworks. I just think there are fewer than people think.