Imho react is to FE development what C++ is to games programming.

And I'm not saying this in a good sense.

In particular their developers demonstrate the same tendencies:

- unwillingness to leave behind all the years of experiences they've built on it. I'm not saying one should just for the sake of changing, but if you encounter certain problems, you should at least consider it

- unwillingness to really try more modern alternatives

- willingness to criticize any alternative, even stating plain wrong things about those. This also includes judging alternatives for the state they were 5/6 years ago, often on very brief experiences

- ability to deflect criticism to their favorite toy with a "skill issues" argument. Oh, it's very easy to squeeze performance, you only need to know how to get good at using useMemo, useCallback, useEffect, etc. Of course, it ain't React being the wrong tool for the problem, or having made design choices that don't fit the problem at hand. Nope, has to be skill issues.

Honestly, every time I read "React is better because X", I know there's just too much engineering nuance missing to have constructive discussions.

▲

interstice 19 hours ago | parent [-]

I remember vividly the chaos before React and what it was like to not know whether it was worth investing in a framework because it might not be around for long. Vue was the first one that I stuck with for a while, but Nuxt was being updated slowly at the time and none of the packages ever seemed quite as seamless as the guys in React land had it. I don't even use more than a handful of unique packages per site generally, I just really need those to work out of the box (tm). It's amazing how many very popular slideshow libraries just.. Break.

I love the idea of a modern & efficient framework that replaces it all, but in terms of hiring, training, maintaining and all of those boring yet vital things it's going to have to be something quite special to make a case for itself. Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.

When did I become this person. How depressing. At least there always fun new tech on the backend to play with on weekends.

▲

epolanski 19 hours ago | parent [-]

> Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.

React's performance are way more severe and ubiquitous and user impacting.

I'd really love to see the websites you're writing in React and lunch a lighthouse or to simulate how do they perform for somebody on a slightly slower connection or not being on the latest iPhone.

Because I know my users include bank clerks or post office cashiers on 10+ year old computers being used at work as much as people on vacation with very poor signal on the beach.

Of course, if you only experience your website from your MBP on cable you thing the issues are only at "10k rows" level.

▲

interstice 16 hours ago | parent [-]

We target <3s to usable on lighthouse mobile, ideally less but I don’t design the sites so only so much I can do about large above fold images etc. the truth is react isn’t that bad compared to latency or other issues on the kind of use case you’re describing

	▲	interstice 16 hours ago \| parent [-]
		I should clarify - this is headless international ecommerce, so that 3s includes localisation, currency, inventory, cart, video, tracking scripts etc. If you'd like 200ms to live on a static site I can do that too, it's just a bit different.