3 ms·

Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular he

Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular here and there.

chrisco255 6y ago
Yeah JS and the ecosystem changed far more from 2010-2015 than in the last 5 years.
- 8bitsrule 6y ago
  Some changes in JS interpreters can be invisible. I recently noticed that an algo (that had worked for ~ 8 years in multiple browsers) had stopped working (for how long? in which browsers?) It (non-rigorously) distinguished 'string integers' from 'string non-integers'. No doubt the required tightening was a benefit, but the breakage was not at all visible. Luckily it was a cosmetic (non-critical) usage.
game_the0ry 6y ago
I have seen a lot of churn react-land alone: * instantiating with React.createClass(), then es6 class components, with functional components and higher-order components, now react hooks * state management, with flux, then redux and mobx, and now context API * bundling with webpack or rollup * types with flow and typescript I could go on. I am sure there's more I am not even aware of.
- chrisco255 6y ago
  Yeah, but swapping out redux for `useReducer` doesn't require you to relearn the core concepts of React. The move from `React.createClass` to `es6` was clearly driven by the JS standards themselves evolving. At any rate, you're not having to rearchitect your whole React app for any of these changes. If you're still using Redux, that's cool, it's not necessary for you to swap it out and state management was never prescribed by React in the first place.
  - lhorie 6y ago
    Though it isn't specific to React, I'd say going from REST to GraphQL is a pretty large change that's been trending these past few years. In React land, I think the churn is mostly around what's considered idiomatic. At some point there were mixins, props-down-events-up, HOCs, old Context, new Context, render props, hooks... On the semantics side, first we started w/ "just recomputing the vdom is faster than poking the DOM a million times", then shouldComponentUpdate and object identity, React.memo, libraries automagically wiring stuff to work around the "just recompute the whole vdom" paradigm. I wouldn't exactly say it's been a stable foundation.
    - testbot123 6y ago
      A lot of those old paradigms you've mentioned have just evolved into new forms, based on lessons learned. Moving from mixins to HOCs, for example, should be relatively easy because they're based on the same concepts [1] and are solving the same types of problems. Another example: React.memo does not replace shouldComponentUpdate, nor is it more idiomatic. React.memo is for /function components/, while shouldComponentUpdate is for class components [2]. Another example: the community wanted a more flexible way of using function components with state, and a way to decouple unrelated state: enter hooks. They're not necessarily more idiomatic, but instead provide an alternate way of structuring components and application logic that fits more use-cases. New context is the same as old context. Hooks just enable another way of interacting with context. [1] https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750 https://medium.com/@dan_abramov/mixins-are-dead-long-live-hi... [2] https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactmemo https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactm...
      - lhorie 6y ago
        > have just evolved into new forms, based on lessons learned Well, yeah, that's what churn means. Consider, for example, that Vue and Angular have more or less stayed the same in terms of how people are supposed to write idiomatic code. The vue equivalent of hooks is very much seen as yet another option on equal footing (if not slightly derided as bandwagoning) since the old ways are just as expressive. When I hear people talking about React hooks, it's certainly not framed in terms of "oh it's just a different way of writing the same thing", but rather "oh it's better because it solves a bunch of issues w/ older idioms". Another example, Mithril.js adopted element-level lifecycle methods (similar to Inferno et al) and the community largely thinks hooks are unnecessary - the last major bump was only major due to obscure semantic technicalities rather than introducing major ways of writing code (Vue is another great example that similar in this regard as well)

Maybe I have been in a corporate bubble, but I haven't seen much churn in the past couple of years. React is everywhere, with a smattering of Vue and Angular here and there.

chrisco255 6y ago

Yeah JS and the ecosystem changed far more from 2010-2015 than in the last 5 years.

8bitsrule 6y ago
Some changes in JS interpreters can be invisible. I recently noticed that an algo (that had worked for ~ 8 years in multiple browsers) had stopped working (for how long? in which browsers?) It (non-rigorously) distinguished 'string integers' from 'string non-integers'. No doubt the required tightening was a benefit, but the breakage was not at all visible. Luckily it was a cosmetic (non-critical) usage.

game_the0ry 6y ago

I have seen a lot of churn react-land alone: * instantiating with React.createClass(), then es6 class components, with functional components and higher-order components, now react hooks * state management, with flux, then redux and mobx, and now context API * bundling with webpack or rollup * types with flow and typescript I could go on. I am sure there's more I am not even aware of.

chrisco255 6y ago
Yeah, but swapping out redux for `useReducer` doesn't require you to relearn the core concepts of React. The move from `React.createClass` to `es6` was clearly driven by the JS standards themselves evolving. At any rate, you're not having to rearchitect your whole React app for any of these changes. If you're still using Redux, that's cool, it's not necessary for you to swap it out and state management was never prescribed by React in the first place.
- lhorie 6y ago
  Though it isn't specific to React, I'd say going from REST to GraphQL is a pretty large change that's been trending these past few years. In React land, I think the churn is mostly around what's considered idiomatic. At some point there were mixins, props-down-events-up, HOCs, old Context, new Context, render props, hooks... On the semantics side, first we started w/ "just recomputing the vdom is faster than poking the DOM a million times", then shouldComponentUpdate and object identity, React.memo, libraries automagically wiring stuff to work around the "just recompute the whole vdom" paradigm. I wouldn't exactly say it's been a stable foundation.
  - testbot123 6y ago
    A lot of those old paradigms you've mentioned have just evolved into new forms, based on lessons learned. Moving from mixins to HOCs, for example, should be relatively easy because they're based on the same concepts [1] and are solving the same types of problems. Another example: React.memo does not replace shouldComponentUpdate, nor is it more idiomatic. React.memo is for /function components/, while shouldComponentUpdate is for class components [2]. Another example: the community wanted a more flexible way of using function components with state, and a way to decouple unrelated state: enter hooks. They're not necessarily more idiomatic, but instead provide an alternate way of structuring components and application logic that fits more use-cases. New context is the same as old context. Hooks just enable another way of interacting with context. [1] https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750 https://medium.com/@dan_abramov/mixins-are-dead-long-live-hi... [2] https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactmemo https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactm...
    - lhorie 6y ago
      > have just evolved into new forms, based on lessons learned Well, yeah, that's what churn means. Consider, for example, that Vue and Angular have more or less stayed the same in terms of how people are supposed to write idiomatic code. The vue equivalent of hooks is very much seen as yet another option on equal footing (if not slightly derided as bandwagoning) since the old ways are just as expressive. When I hear people talking about React hooks, it's certainly not framed in terms of "oh it's just a different way of writing the same thing", but rather "oh it's better because it solves a bunch of issues w/ older idioms". Another example, Mithril.js adopted element-level lifecycle methods (similar to Inferno et al) and the community largely thinks hooks are unnecessary - the last major bump was only major due to obscure semantic technicalities rather than introducing major ways of writing code (Vue is another great example that similar in this regard as well)