If not React, then what?

> Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.

Yes, in that case, i.e., if it were a problem we had. It's NOT a problem we have though. That's my point. Not currently. Not in our context.

> But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them

Not exactly React, but there was ActiveX, Flash, and Java Applets. Thick clients came first. It wasn't until IE6 where there some AJAX was viable. React came later to address additional shortcomings: procedurally updating the state of the document via jquery got complicated, and large organizations with poor development practices (e.g., facebook) struggled to maintain control of their application. They came up with React to help with this, and it did, but it brought its own host of problems. Declarative UI was what we always had with server rendering. They just allowed it to update. Btw, this isn't a new idea. We had something like this with ASP.NET as well, but that included the server.

Meanwhile, people like Chris McCord had already built a syncing library for Rails to solve these problems and, being fed up with the performance at that point, went to Elixir where he eventually built Phoenix LiveView. By then, React already had significant market share. Turbo's previous incarnation came out before then and its current one came out around that time or slightly after. Combined with Ruby's performance improvements over time, it was quite viable for many apps.

Also, note what's happening in React -- it's moving towards more server rendering. People realized they lost something by doing client only and they're trying to get back to it. Remix is an ode to the simplicity of old (which is really the simplicity of now, but they don't want to give up their React Components). I can't blame them in a way, React is a lot of fun to write a lot of the times.

> Maybe they've found themselves a good unified state abstraction now...

We've always had the database. That's insufficient for highly interactive applications where you need client-side state, which is likely what you mean by "unified". So yes, if you need "unified" state, and specifically the ability to change your UI based on changes to that state, React is great, or any of the other libs. The author was specifically concerned about React's current state (e.g. legacy IE6 support) and I'm specifically concerned about people reaching for React when they don't need it. That's because I've done it, I've seen people do it, and I see people continuing to preach the React orthodoxy which will lead to more people doing it. This thread is full of it.

Whether or not a person recognizes it, HTMX, Turbo, LiveView and its kind have greatly narrowed that gap. They've made server rendering just as capable at highly-interactive UIs in many more cases than many people think.

> I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless.

Sure, I can relate to this. But this is different than spreading FUD about having to learn a new language. That's easy. That's the easiest thing we have to do. I'm not suggesting to do it flippantly. I'm suggesting that sometimes it's worth it. When it's worth it, you do it and it's not a big deal.

Redux uses context but does not do full re-renders except if you are using it wrong. It does a shallow compare on the object resulting from your selector to decide whether or not to re-render a component.

That being said, none of the React projects I've had the chance of working on in the last 5 or 6 years has used Redux, so stating that it's been the go-to state management library for nearly a decade kind of sounds weird to me.

yes, htmx is very much suggesting returning HTML rather than JSON from the server, and collapsing a layer of complexity in the process. this has turned out very well for some applications, dramatically lowering complexity:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

looking at caption.me, I see nothing that couldn't be effectively addressed using this hypermedia approach, and I suspect it would simplify the application. You don't worry about "breaking the other side" because there is no other side: everything is hypermedia, in the original mode of the web

I don't think PHP has much to do with htmx: you can use PHP if you'd like on the server side, but you can use whatever server side technology you'd like to produce HTML. People are using Go, Java, Kotlin, Scala, Rust, Python, Lisp, etc. with it and it works fine. It's a generalization of hypermedia controls[1] (anchors and forms) and, like anchors and forms, has no opinion on what the server side looks like.

One piece of good news regarding htmx is that the API is not going to change dramatically in perpetuity, so there is no treadmill to keep up with.

[1] - https://dl.acm.org/doi/pdf/10.1145/3648188.3675127

Prop drilling refers to depth, not width - you had to add the props to every intermediate component between where the state is stored and where it's used. Some of us tried to come up with nested usage patterns so at least the intermediate components didn't need to know about the structure and it wouldn't be a pain when moving things around, but it still wasn't very good.

> No. You are just dealing with bad code. There are highly performant web apps written in React.

cool maybe I'll see one one day

> React gives you many tools to skip unnecessary work and reduce latency, such as shouldComponentUpdate, and assigning keys to elements in a collection

but do people use these outside of demos

I have an high end CPU with 32GB of RAM and almost every single website I use gives me a worse experience than I got 20 years ago

> if one writes bad frontend code, well the cost is diffuse and many don't notice it.

exactly, and that's why we are where we are today - surrounded on all sides by websites covered in glue, because bad experience has been completely normalised, all for what? Some abstract notion of developer convenience that results in almost every case in a significantly worse experience by almost any metric.