I actually think this is pretty much exactly what the React team has done. They've made very few breaking changes over time; you can still use mixins, React.createClass, and most of the other syntax from 2015 if you really want to. You don't have to use hooks, suspense, or any of the other new features, and they've been quite explicit about their commitment to avoiding churn (because Facebook's codebase also has tons of legacy components that they don't want to rewrite either).
Or if your argument is just that you should have an option to use a React bundle that is smaller in size and excludes the new functionality -- React as a library is actually significantly smaller than it was in earlier versions [0]. They've applied a lot of learnings and improved the architecture over time, such that the framework is faster and leaner under the hood despite still supporting the same legacy APIs.
For what it's worth, I don't think the React team is bored; I think they're trying to conceive of frontend engineering as something more holistic than just the view layer. For example, old-school React is great for encapsulating and reusing bits of view as components, but how do we encapsulate and reuse bits of business logic or interactions? With hooks. How do I compose together my components to give a seamless loading experience, rather than a bunch of spinners and holes in the UI? With suspense. They're not really diverging from a view layer, just thinking at a higher level about how a view is engineered and how to provide primitives and abstractions that make it easy to build a good, complete UX (not just layout).
Thank you for this eloquent wording, you've saved me a lot of time and energy in my responses to people who don't get this point.
It is. Because through experience developers realized these concerns need to be addressed, and handled... by something. It is unavoidable to have a useful application. Having the framework integrated to help you do so is much less painful than piecing together separate tools, or having 20 different libraries construct their own way to do so (if it is solveable in a uniform way that simply needs to be advocated and agreed upon).
But in any case, why can't you just not use them?
What is the pain point caused by ignoring the changes... and choosing separate tools to solve these problems if that's what you prefer?
We’d all be pissed if the sizzle selector wasn’t awesome and well thought out api.
What I keep seeing with React is really bad api design with things like hooks (because classes are so complicated, someone link that documentation post) and redux is horrific boilerplate to manage global state.
Ok no problem, don’t use it. Discourse ends there right?
No I’m sorry, reducers, hooks, ‘suspense’ stuff is not intuitive. This needs to be properly discussed.
Can I possibly even start the discussion at why the hell these things are being named in this way? Is that not a start? Functions and Classes are stupid? A debounce function that’s possibly a promise, stuff we know about, is suddenly like the ‘suspense’ api? Does any thought go into this anymore for how average developers have to approach this horseshit?
This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class.
On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C).
On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers.
(On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".)
Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.
Overall I'd agree, but I don't think concurrent mode falls into that category. It really is a view-layer thing, and it's something that's not really feasible to do from the outside (unlike, say, state management).
Except for those of us using React Native, where functional components break live editing!
Thankfully a fix for that is coming soon, in a other 2 or 3 months maybe I can start using hooks... :/
React used to be great, and to some degree it still is, but somehow its contributor has a vision to make it our generation's J2EE, which IMO, is due to be hated by a lot of people, including me.
No, you're just not solving problems at the scale Facebook is. You probably don't need to use Suspense.
With each React update however, I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. I worry that it will become just another bloated "framework" with unnecessary complexity and drive me into the lighter weight and more focused alternatives such as VueJS or Svelte. Perhaps the React team is getting bored?
IMO I'd like to see a base ReactJS with these advanced features being add-ons in some fashion. Keep the version I like to use lean and the complexity just where I like it.