[ysavir]

That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.

[cloverich]

I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.

The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.

[laurencerowe]

> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.

This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.

Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.

[throwawayffffas]

The point would me much better served if the article compared react from 2014 to react today.

As others have noted working with react after having worked with backbone, jQuery and ember felt like a breath of fresh air.

It felt that was we were doing was same again, and I would argue understandable. 11ish years later cruft has pilled own to dev experience detriment.

[echelon]

The job is to deliver complex software with ever changing requirements with a fungible team of engineers.

I'd say React is doing swimmingly at that job description.

For small, artisanal projects, there are lots of other choices and priorities.

I'm merely reiterating the blog's thesis.

[qudat]

Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.

[flufluflufluffy]

Which is the case for every library ever written