6 ms·

The problem with frameworks like React is that the version you’re using and its API will become outdated in no time. We started using React in 2014 and their ap

The problem with frameworks like React is that the version you’re using and its API will become outdated in no time. We started using React in 2014 and their approach to state management changed at least three times since then. Not to mention build systems, tooling and libraries. In my experience that leads to a large fraction of developer time (10-30 percent I’d say) just going into often pointless refactoring that is necessary to keep up with the framework ecosystem, because you don’t want to run “legacy code”. Most large organizations seem to accept that but for smaller ones it can be quite a burden. The beauty of the native JS APIs is that they are relatively stable: things that worked 10 years ago still work today, and can be done in the same way. Also, standard adherence in browsers has become much better so if you do not need to support legacy browsers like IE you can get away with writing pure JS without any polyfills or frameworks.

jtms 7y ago
Browser APIs have changed quite a bit in the last 10 years. Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs. Ten years ago you would have never dreamed of trying to build complex front end behavior without something like JQuery, but now it’s totally unnecessary as all browsers mostly adhere to the standards. I guess my point is I don’t think React has changed any more or less than browser APIs - both have just steadily updated best practices just like any other piece of software since ever.
- dmitriid 7y ago
  > Browser APIs have changed quite a bit in the last 10 years. They really haven't. > Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs. Once again, there really haven't been. Yes, there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.
  - danpeddle 7y ago
    In 2010, browsers supporting rounded corners were considered exotic. It’s totally, totally different now.
    - jtms 7y ago
      yeah seriously... in 2010 i am pretty sure we were still rounding corners via background images in css
    - dmitriid 7y ago
      It's not a change. It's an addition of APIs (css in this case)
  - deleted 7y ago
    [deleted]
  - jtms 7y ago
    Just because the APIs remain largely backwards compatible does not mean that they didn't change. Just the fact that querySelector and querySelectorAll was introduced and started actually being usable across all the major browsers is a huge change IMHO.
    - dmitriid 7y ago
      I... I wrote that as my last paragraph: there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.
root_axis 7y ago
Why refactor if you don't see any value in it? There is no reason you have to refactor.
- kakwa_ 7y ago
  If you don't refactor and update your dependencies regularly you can easily end-up in a corner. You can be hit by a bug in your dependencies, be it a functional one or a security one, but if your dependencies are completely out of date and there is tons of API incompatibilities between the version you are using, and the version implementing the bug fix, it will be really painful and take a long time to update, with stakeholders breathing down your neck expecting a fix asap. Also, maintaining old tool chains can be a real drag (maintaining older building hosts, developer machines or VMs). Updating frequently to be near enough the latest version is generally preferable.
jakearmitage 7y ago
This. Framework maintenance is something that takes a lot of time from our development team. Compared to other ecosystems (Python, Java), the frontend teams spend much more time dealing with updates to their stack (webpack, react).
- ng12 7y ago
  Once a year I update my webpack, React, and TypeScript versions. And this is for a completely custom webpack toolchain. I don't think that's unusual compared to other technologies.
dntrkv 7y ago
When has React's approach to state management changed? The only change I know of is the introduction of the useState hook, but you don't have to use it. The React team has done stellar job of maintaining a stable API with very minimal breaking changes. The only major breaking changes I can think of is the move of React.createClass to react-create-class and replacing the lifecycle methods through a slow and steady push over multiple major versions. I'm sure there were some smaller ones, but nothing that required any significant amount of time to fix. As far as build systems and tooling, that's only as complex as you want it to be and doesn't have to change with the seasons. I've been using the same Webpack/Babel/React setup on one of my projects for about 7 years now with minimal work on my end (the only major upgrade was Babel 6 > 7, and Webpack 2 to 3, which took about maybe half a day to complete both).
- ThePhysicist 7y ago
  Talking about global state management (not local state/props), when we started working with React their recommended method of state management was via Mixins. Those became deprecated in 2017 (I think). They then recommended to use only higher-order components (HOCs) for state management. Last year they deprecated this in favor of hooks. The context API has changed several times as well, though since that was never meant to be an end-user API I think it's less problematic. They also deprecated a bunch of life cycle methods (e.g. componentWillMount), though that is probably also a minor nuisance. As you said you can still use the old ways of managing state (except mixins I think which were really removed for good), the thing is just that most of the ecosystem of third-party libraries (routing, state management etc.) quickly moves to the latest paradigm, so if you do not want to run outdated code with potential security vulnerabilities you will need to constantly refactor your code as well just to keep up with the ecosystem.
  - acemarke 7y ago
    You're conflating several different things: patterns specifically recommended by the React team, patterns in vogue in the community, specific libraries from the community, and actual API changes in React itself. The React team did definitely tell folks to stop using mixins and try using HOCs instead [0]. HOCs have some limitations as well, and hooks are designed to help address those [1], but it doesn't mean HOCs are suddenly broken and you can't use them. React's actual APIs are quite stable. As the React team has pointed out, Facebook has something like 100K components in their codebase, and many of those are still using older APIs. For example, even `React.createClass` still works. Granted, it was moved to an external package `create-react-class` package a while back because it's discouraged, but the API still works (and that's what had mixin support). The community jumped on render props, and the React team never specifically recommended them as a generally-encouraged pattern that I know of. The only example of render props in React's actual APIs is the `<Context.Consumer>` component. The context API never "changed", per se. There's the original `this.context` API, which is now definitely considered legacy and deprecated, _but_ it still works fine as of React 16.x. The new `createContext()` API, added in React 16.3, is a new API that solves the same use case. The deprecation of lifecycle methods is real, but the React team has been warning about that for a while. Note that even in future code, renaming them to `UNSAFE_componentWillReceiveProps` will still work, and the React team has provided codemods to make that fix if you want to keep using that code as-is. The churn in the resulting ecosystem is a more valid point of concern. React-Router is a frequent target of complaints. That's _partially_ justified, as their API has changed a couple times. As a Redux maintainer, I'm very happy that we've managed to keep the React-Redux API stable across multiple major versions and internal rewrites [2]. If you were using React-Redux v4.x, you _should_ be able to jump to the current v7.x just by bumping the package version. [0] https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu... [1] https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html [2] https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
jeremiep 7y ago
Been using react transparently through clojurescript's reagent for years and was never hit by any of react's API changes. The problem usually isn't react, but that most projects using it directly use it wrong.
redis_mlc 7y ago
> things that worked 10 years ago still work today I have vanilla-js code from 1998 that still works unchanged in 2020.
- eyegor 7y ago
  I think the main pain point is towards front end appearance/interactions. Js as a language has gotten more ergonomic, but it's been Turing complete forever. As a practical matter, the pain comes when you say "I want to align x" and come to learn that every browser has different flags to accomplish the task. I'm sure you've seen the fat stacks of moz/ie/opera checks and flags before. I know that example is bad, but I can't think of a good one at the moment, I rarely touch front end.
  - adrianhel 7y ago
    That is not the case anymore. Vendor prefixes are discouraged and seldom needed.

jtms 7y ago

Browser APIs have changed quite a bit in the last 10 years. Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs. Ten years ago you would have never dreamed of trying to build complex front end behavior without something like JQuery, but now it’s totally unnecessary as all browsers mostly adhere to the standards. I guess my point is I don’t think React has changed any more or less than browser APIs - both have just steadily updated best practices just like any other piece of software since ever.

dmitriid 7y ago
> Browser APIs have changed quite a bit in the last 10 years. They really haven't. > Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs. Once again, there really haven't been. Yes, there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.
- danpeddle 7y ago
  In 2010, browsers supporting rounded corners were considered exotic. It’s totally, totally different now.
  - jtms 7y ago
    yeah seriously... in 2010 i am pretty sure we were still rounding corners via background images in css
  - dmitriid 7y ago
    It's not a change. It's an addition of APIs (css in this case)
- deleted 7y ago
  [deleted]
- jtms 7y ago
  Just because the APIs remain largely backwards compatible does not mean that they didn't change. Just the fact that querySelector and querySelectorAll was introduced and started actually being usable across all the major browsers is a huge change IMHO.
  - dmitriid 7y ago
    I... I wrote that as my last paragraph: there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.

root_axis 7y ago

Why refactor if you don't see any value in it? There is no reason you have to refactor.

kakwa_ 7y ago
If you don't refactor and update your dependencies regularly you can easily end-up in a corner. You can be hit by a bug in your dependencies, be it a functional one or a security one, but if your dependencies are completely out of date and there is tons of API incompatibilities between the version you are using, and the version implementing the bug fix, it will be really painful and take a long time to update, with stakeholders breathing down your neck expecting a fix asap. Also, maintaining old tool chains can be a real drag (maintaining older building hosts, developer machines or VMs). Updating frequently to be near enough the latest version is generally preferable.

jakearmitage 7y ago

This. Framework maintenance is something that takes a lot of time from our development team. Compared to other ecosystems (Python, Java), the frontend teams spend much more time dealing with updates to their stack (webpack, react).

ng12 7y ago
Once a year I update my webpack, React, and TypeScript versions. And this is for a completely custom webpack toolchain. I don't think that's unusual compared to other technologies.

dntrkv 7y ago

When has React's approach to state management changed? The only change I know of is the introduction of the useState hook, but you don't have to use it. The React team has done stellar job of maintaining a stable API with very minimal breaking changes. The only major breaking changes I can think of is the move of React.createClass to react-create-class and replacing the lifecycle methods through a slow and steady push over multiple major versions. I'm sure there were some smaller ones, but nothing that required any significant amount of time to fix. As far as build systems and tooling, that's only as complex as you want it to be and doesn't have to change with the seasons. I've been using the same Webpack/Babel/React setup on one of my projects for about 7 years now with minimal work on my end (the only major upgrade was Babel 6 > 7, and Webpack 2 to 3, which took about maybe half a day to complete both).

ThePhysicist 7y ago
Talking about global state management (not local state/props), when we started working with React their recommended method of state management was via Mixins. Those became deprecated in 2017 (I think). They then recommended to use only higher-order components (HOCs) for state management. Last year they deprecated this in favor of hooks. The context API has changed several times as well, though since that was never meant to be an end-user API I think it's less problematic. They also deprecated a bunch of life cycle methods (e.g. componentWillMount), though that is probably also a minor nuisance. As you said you can still use the old ways of managing state (except mixins I think which were really removed for good), the thing is just that most of the ecosystem of third-party libraries (routing, state management etc.) quickly moves to the latest paradigm, so if you do not want to run outdated code with potential security vulnerabilities you will need to constantly refactor your code as well just to keep up with the ecosystem.
- acemarke 7y ago
  You're conflating several different things: patterns specifically recommended by the React team, patterns in vogue in the community, specific libraries from the community, and actual API changes in React itself. The React team did definitely tell folks to stop using mixins and try using HOCs instead [0]. HOCs have some limitations as well, and hooks are designed to help address those [1], but it doesn't mean HOCs are suddenly broken and you can't use them. React's actual APIs are quite stable. As the React team has pointed out, Facebook has something like 100K components in their codebase, and many of those are still using older APIs. For example, even `React.createClass` still works. Granted, it was moved to an external package `create-react-class` package a while back because it's discouraged, but the API still works (and that's what had mixin support). The community jumped on render props, and the React team never specifically recommended them as a generally-encouraged pattern that I know of. The only example of render props in React's actual APIs is the `<Context.Consumer>` component. The context API never "changed", per se. There's the original `this.context` API, which is now definitely considered legacy and deprecated, _but_ it still works fine as of React 16.x. The new `createContext()` API, added in React 16.3, is a new API that solves the same use case. The deprecation of lifecycle methods is real, but the React team has been warning about that for a while. Note that even in future code, renaming them to `UNSAFE_componentWillReceiveProps` will still work, and the React team has provided codemods to make that fix if you want to keep using that code as-is. The churn in the resulting ecosystem is a more valid point of concern. React-Router is a frequent target of complaints. That's _partially_ justified, as their API has changed a couple times. As a Redux maintainer, I'm very happy that we've managed to keep the React-Redux API stable across multiple major versions and internal rewrites [2]. If you were using React-Redux v4.x, you _should_ be able to jump to the current v7.x just by bumping the package version. [0] https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu... [1] https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html [2] https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

jeremiep 7y ago

Been using react transparently through clojurescript's reagent for years and was never hit by any of react's API changes. The problem usually isn't react, but that most projects using it directly use it wrong.

redis_mlc 7y ago

> things that worked 10 years ago still work today I have vanilla-js code from 1998 that still works unchanged in 2020.

eyegor 7y ago
I think the main pain point is towards front end appearance/interactions. Js as a language has gotten more ergonomic, but it's been Turing complete forever. As a practical matter, the pain comes when you say "I want to align x" and come to learn that every browser has different flags to accomplish the task. I'm sure you've seen the fat stacks of moz/ie/opera checks and flags before. I know that example is bad, but I can't think of a good one at the moment, I rarely touch front end.
- adrianhel 7y ago
  That is not the case anymore. Vendor prefixes are discouraged and seldom needed.