5 ms·

My point is that this sort of thing doesn't happen so lightly in other ecosystems. And the "you don't have to use it" excuse isn't used when the project clearly

by spion 3y ago

My point is that this sort of thing doesn't happen so lightly in other ecosystems. And the "you don't have to use it" excuse isn't used when the project clearly wants to move in that direction: - others will jump on the feature and use it. you might not have to use it but libraries you depend on may decide otherwise and rewrite - you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. - you will slowly see bugs being neglected if they're not about the new and shiny. - there is no equivalent of useContext for class components So the word "supports" here carries very little weight in practice because the rest of the ecosystem constantly rewrites.

throwitaway1123 3y ago
> My point is that this sort of thing doesn't happen so lightly in other ecosystems. React has been around for 10 years (almost 11 since we're a few days away from 2024). Many of the ecosystems you're holding up as the epitomes of stability have had their fare share of large scale changes in that same time frame. Remember go before generics, or Rust before async landed [1]? Elixir's Phoenix didn't even have its first commit when React was released [2]. > there is no equivalent of useContext for class components Class components can still use context [3]. They obviously can't use the useContext hook, because class components aren't compatible with hooks, but that's kind of a tautology. > you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. Library authors moved to hooks because sharing stateful logic was difficult before hooks. I never bought into the GraphQL hype train, but I remember there being a ton of verbose render props necessary to make GraphQL libraries like Apollo work before hooks. I don't think anyone really complained about data fetching libraries adopting hooks. You could argue that the react devs should have created the perfect library in 2013 complete with hooks, but I can forgive them for not having perfect foresight. Like I said, if an API changes occasionally over a decade I'm ok with it. Technology should be stable, not frozen. [1] https://areweasyncyet.rs/ https://areweasyncyet.rs/ [2] https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o [3] https://legacy.reactjs.org/docs/context.html#classcontexttype https://legacy.reactjs.org/docs/context.html#classcontexttyp...
- spion 3y ago
  You can't use more than one context in React classes "React" has been around for 10 years but in practice its been 3.5 different frameworks - the original - the class version (still close enough to original) - hooks version (largely a whole different concept and "compatible" only superficially while the rest of the ecosystem starts writing incompatible things) - server components, and `use`, which monkey patch fetch and already broke half of the ecosystem. And no, hooks are still far from perfect and are infact very unintuitive and awkward to pretty much anyone who hasn't used React. Additionally, there were designs possible to evolve from class components, its just that the React team cared more about - "innovation", - "functional" aesthetic preferences - enabling a DCE compiler rather than compatibility and continuity Example design that would prioritise compatibility and continuity while still enabling all the current features of hooks: https://news.ycombinator.com/item?id=35192312 https://news.ycombinator.com/item?id=35192312 Again, this is _not enough_ attention to backward compatibility and stability in other ecosystems, even older ones like Python.
  - spion 3y ago
    The problem isn't just react though. Most libraries in JS land just don't prioritise interfaces, compatibility and colaboration, instead opting for a "I'm just gonna build my own thing and not care about anything else out there" mentality. Lets look at that Rust comparison and see how the equivalent situation looks like for JS. Before async-await, Rust had a variety of libraries implementing something close to Futures. They all largely standardized on the Future trait from the futures crate, which made it possible to write compatible library code that could build on top of any of them. There was a bit of an issue with compatibility as the trait essentially moved into std and some compatibility shims were needed, but after that a lot of the ecosystem adopted it and its possible to write runtime-independent code In contrast in JS land, we had callbacks which were not even values, Promises (which had a working group that actually cared about compatibility), monadic Futures, observables, thunks, event-based interfaces, a variety of libraries. This came to be dominated with node-style callbacks, and then what got standardized were promises which instantly made most of the library ecosystem incompatible with the standardized syntax. Both ecosystem have had these challenges, but to me it seems clear that the Rust community approached it with more care and thought on average. Going beyond async-await, we can see similar patterns in the rest of the ecosystem. We have: - half a dozen different component frameworks and not one has thought to define an compatible component interface that anyone could implement. - 10 different popular libraries for manipulating standard library collections, but not one common protocol or trait (other than iterable and concatspreadable) that would make them largely work with other custom collections (e.g. MobX reactive collections or similar) - 5 different popular bundlers and 10 older ones, but not one common trait, interface or standard for writing bundler plugins - at a certain point, we had 3 different ways to define monorepo workspaces between npm, pnpm and yarn So for a variety of reasons we have a very "internally incompatible" ecosystem. You can barely get components to work together, and what works together today is almost guaranteed to break tomorrow. I think that if we recognize this is a problem collectively, there may be a way out. There is very high interest in some maintainers for doing this, especially those that care about compatibility. This is because one-sided care is not enough - the side you want to be compatible with has to care and prioritize it too. Those maintainers could decide to form a sub-community that prioritizes compatibility and continuity amongst them, as well as a promise to their users. The recognition has to be more widespread than just in maintainers though, as frameworks that have done this before (e.g. Ember) have been largely left behind due to hype propping up the latest shiniest thing.

by spion 3y ago

throwitaway1123 3y ago

> My point is that this sort of thing doesn't happen so lightly in other ecosystems. React has been around for 10 years (almost 11 since we're a few days away from 2024). Many of the ecosystems you're holding up as the epitomes of stability have had their fare share of large scale changes in that same time frame. Remember go before generics, or Rust before async landed [1]? Elixir's Phoenix didn't even have its first commit when React was released [2]. > there is no equivalent of useContext for class components Class components can still use context [3]. They obviously can't use the useContext hook, because class components aren't compatible with hooks, but that's kind of a tautology. > you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. Library authors moved to hooks because sharing stateful logic was difficult before hooks. I never bought into the GraphQL hype train, but I remember there being a ton of verbose render props necessary to make GraphQL libraries like Apollo work before hooks. I don't think anyone really complained about data fetching libraries adopting hooks. You could argue that the react devs should have created the perfect library in 2013 complete with hooks, but I can forgive them for not having perfect foresight. Like I said, if an API changes occasionally over a decade I'm ok with it. Technology should be stable, not frozen. [1] https://areweasyncyet.rs/ https://areweasyncyet.rs/ [2] https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o [3] https://legacy.reactjs.org/docs/context.html#classcontexttype https://legacy.reactjs.org/docs/context.html#classcontexttyp...

spion 3y ago
You can't use more than one context in React classes "React" has been around for 10 years but in practice its been 3.5 different frameworks - the original - the class version (still close enough to original) - hooks version (largely a whole different concept and "compatible" only superficially while the rest of the ecosystem starts writing incompatible things) - server components, and `use`, which monkey patch fetch and already broke half of the ecosystem. And no, hooks are still far from perfect and are infact very unintuitive and awkward to pretty much anyone who hasn't used React. Additionally, there were designs possible to evolve from class components, its just that the React team cared more about - "innovation", - "functional" aesthetic preferences - enabling a DCE compiler rather than compatibility and continuity Example design that would prioritise compatibility and continuity while still enabling all the current features of hooks: https://news.ycombinator.com/item?id=35192312 https://news.ycombinator.com/item?id=35192312 Again, this is _not enough_ attention to backward compatibility and stability in other ecosystems, even older ones like Python.
- spion 3y ago
  The problem isn't just react though. Most libraries in JS land just don't prioritise interfaces, compatibility and colaboration, instead opting for a "I'm just gonna build my own thing and not care about anything else out there" mentality. Lets look at that Rust comparison and see how the equivalent situation looks like for JS. Before async-await, Rust had a variety of libraries implementing something close to Futures. They all largely standardized on the Future trait from the futures crate, which made it possible to write compatible library code that could build on top of any of them. There was a bit of an issue with compatibility as the trait essentially moved into std and some compatibility shims were needed, but after that a lot of the ecosystem adopted it and its possible to write runtime-independent code In contrast in JS land, we had callbacks which were not even values, Promises (which had a working group that actually cared about compatibility), monadic Futures, observables, thunks, event-based interfaces, a variety of libraries. This came to be dominated with node-style callbacks, and then what got standardized were promises which instantly made most of the library ecosystem incompatible with the standardized syntax. Both ecosystem have had these challenges, but to me it seems clear that the Rust community approached it with more care and thought on average. Going beyond async-await, we can see similar patterns in the rest of the ecosystem. We have: - half a dozen different component frameworks and not one has thought to define an compatible component interface that anyone could implement. - 10 different popular libraries for manipulating standard library collections, but not one common protocol or trait (other than iterable and concatspreadable) that would make them largely work with other custom collections (e.g. MobX reactive collections or similar) - 5 different popular bundlers and 10 older ones, but not one common trait, interface or standard for writing bundler plugins - at a certain point, we had 3 different ways to define monorepo workspaces between npm, pnpm and yarn So for a variety of reasons we have a very "internally incompatible" ecosystem. You can barely get components to work together, and what works together today is almost guaranteed to break tomorrow. I think that if we recognize this is a problem collectively, there may be a way out. There is very high interest in some maintainers for doing this, especially those that care about compatibility. This is because one-sided care is not enough - the side you want to be compatible with has to care and prioritize it too. Those maintainers could decide to form a sub-community that prioritizes compatibility and continuity amongst them, as well as a promise to their users. The recognition has to be more widespread than just in maintainers though, as frameworks that have done this before (e.g. Ember) have been largely left behind due to hype propping up the latest shiniest thing.