> I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
Vue2 worked a different way from inception (probably gaining from being able to see what react did and do something different), it tracks dependencies via the data property, so it does not require you to specify manually. Heavy list rendering isn't what I was referring to, it's manual dependency tracking -- there's a separate pattern for large list rendering.
It's not all sunshine and rainbows, but this is a better default.
> I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all.
As recently as October this year breaking changes were an issue[0].
> There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it...
No it's not, and that's the thing. There are even more codebases that are doing just fine with services + views (popularized by angular, ember). The main benefit I see is the time-travel property of state stores, but that's not that hard to do with other approaches either. This is the cargo culting in action -- everyone just assumes "oh you need state-management? well redux it is then, start reading up on reducers". Redux is so obtuse that redux-toolkit[1] exists. Again, the promise was simplicity but what you got was complexity.
> Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity.
So that's the thing, all that "moderate complexity" stuff you'd have been up and running with in Vue 2 on the first day. You can read the Vue docs in a few hours, and write an app that handles state reasonably well in that same day. It's not that it's abstracted away, it's free of unnecessary abstraction which is what makes it simple.
> That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app...
Here's another red flag for me -- if your library needs me to download a zipfile with everything pre-setup (because not doing so would be difficult), then your library is complex. Maybe I'm the only one that still creates new folders and puts files in myself, but I try not to allow this kind of complexity.
I want to be clear -- I don't doubt react's usefulness to enterprise. I do not doubt it's production worthiness or ecosystem -- the result of the hype and the popularity is that people have made it production ready, contributed an intense amount, and built great stuff with it. It is the premier front end component-based library, I do not doubt that. It essentially re-introduced the idea of component-based frameworks (I'd argue Backbone Views were already there, as well as Angular Directives, some MVVM stuff etc), and made is seem simple and sexy.
> Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.
You're right, they can't but I think it's more of a case of Angular2 being a failed migration (and maybe apply/digest being horrible there too), it was the enterprise choice before React. I think you have it backwards -- react receives significant improvements to it's core and ecosystem because it is popular, and maintained by a large FANG company. It has endured rewrites (which take significant manpower) smaller projects could not undertake because of said funding.
Funnily enough, this brings me back to Dart -- Dart1 was a trainwreck, and Dart2 is way better but in my opinion is trash in comparison to newer statically type checked languages designed around the same time (Rust, Go, Swift, D, etc). I know however, that Dart will never die, as long as it is used in Fuschia or at Google in general. People were probably saying the same kinds of things about Dart1 and they'll say nice things about Dart2, but I still prefer Typescript because it a type system more suited to my tastes.
I don't think I can convince you that react is complex and has warts that other libraries (in particular Vue) don't have. It sounds like you're productive and find it easy, that's great by all means use it -- whatever makes you the most productive.
[0]: https://reactjs.org/blog/2020/10/20/react-v17.html
[1]: https://redux-toolkit.js.org/