6 ms·

Stuff like this is what puts me off React: https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://

Stuff like this is what puts me off React: https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/03/29/react-v-16-3.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d... It's at v16, and they're still making major changes to the basic component lifecycle, deprecating things, and then almost immediately having to write articles to teach against anti-patterns that already arisen in the new APIs! A programming model that is so unintuitive people still cannot use it right, even after so many years, does not seem like a great bet to me.

djstein 8y ago
I'm not sure if you actually have ever used React but every single major version update is non breaking. The topics discussed in the link provided are discussing how an internal library is being updated (Context API) and how these functions are being depreciated in version 17 (https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin...). The above depreciations are functions that typically should not be used in a v16 React application anyway! Using them typically means there lies a bug in your props updating logic.
- flukus 8y ago
  > I'm not sure if you actually have ever used React but every single major version update is non breaking. That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
  - gr__or 8y ago
    A major version change of React is different from a major version change in Angular. I upgraded several React apps of variying sizes from 14 to 17 over time and none of these upgrades took more than an hour. Don't get confused by the version labeling scheme.
city41 8y ago
React has always opted for better performance even if that causes the API to be harder to use. This can be seen in how setState() behaves differently depending on when you call it, keys, and now getDerivedStateFromProps. I've been using React since its inception and just the other day I got stuck with a gotcha on keys I was not expecting. Not saying this is good or bad, it's just the approach React took.
IloveHN84 8y ago
The major problem is that with the introdu of progressive web apps, people found easy to implement mobile apps, at the cost of sweating many hours on following React API changes, instead of learning native platforms API. This applies also to who is using Electron instead of native API on desktop.
- tspike 8y ago
  It continually amazes me the contortions people will put themselves through just to be able to keep writing Javascript.

djstein 8y ago

I'm not sure if you actually have ever used React but every single major version update is non breaking. The topics discussed in the link provided are discussing how an internal library is being updated (Context API) and how these functions are being depreciated in version 17 (https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html https://reactjs.org/blog/2018/03/27/update-on-async-renderin...). The above depreciations are functions that typically should not be used in a v16 React application anyway! Using them typically means there lies a bug in your props updating logic.

flukus 8y ago
> I'm not sure if you actually have ever used React but every single major version update is non breaking. That would be fine if they were making major releases every 2+ years, when you release a major version on average of 3 times a year it's incredibly unstable. A typical upgrade will be jumping several versions.
- gr__or 8y ago
  A major version change of React is different from a major version change in Angular. I upgraded several React apps of variying sizes from 14 to 17 over time and none of these upgrades took more than an hour. Don't get confused by the version labeling scheme.

city41 8y ago

React has always opted for better performance even if that causes the API to be harder to use. This can be seen in how setState() behaves differently depending on when you call it, keys, and now getDerivedStateFromProps. I've been using React since its inception and just the other day I got stuck with a gotcha on keys I was not expecting. Not saying this is good or bad, it's just the approach React took.

IloveHN84 8y ago

The major problem is that with the introdu of progressive web apps, people found easy to implement mobile apps, at the cost of sweating many hours on following React API changes, instead of learning native platforms API. This applies also to who is using Electron instead of native API on desktop.

tspike 8y ago
It continually amazes me the contortions people will put themselves through just to be able to keep writing Javascript.