5 ms·

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are const

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.

nicoburns 6y ago
React has been stable since ~2015, and there are no signs of that changing.
- madoublet 6y ago
  I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
  - NiceNamesOrg 6y ago
    Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
    - madoublet 6y ago
      My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.
    - onion2k 6y ago
      Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.
      - nicoburns 6y ago
        Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.
      - hackerfromthefu 6y ago
        But not all of your packages!
      - hatch_q 6y ago
        This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)
        hajile 6y ago
        I did that migration on a very large react project (hundreds of thousands of lines). As I recall, after dealing with warnings for the later 15.x releases, the upgrade was seamless. They're also good about creating codemods to make the transition easier -- something somewhat rare in the world of software libraries.
    - hatch_q 6y ago
      I tried to upgrade a substantial codebase from vue 2 to 3 and hit a brick wall with Vuex early on.
- JoeyJoJoJr 6y ago
  I would say that the React ecosystem as a whole is in constant flux, which is what really matters.
  - nicoburns 6y ago
    How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.
    - hackerfromthefu 6y ago
      As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant. React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s
      - nicoburns 6y ago
        > react apps often have dozens of additional packages. And the churn on these packages is significant. IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.
        hackerfromthefu 6y ago
        I agree, for a significant portion of the packages yet not all. Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)
- ryanbrunner 6y ago
  I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it. Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.
  - nicoburns 6y ago
    The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features). At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style. If you feel like you need to upgrade then I think that on you, not the framework.
  - futureproofd 6y ago
    Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects. Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.
    - debaserab2 6y ago
      Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?
- Cthulhu_ 6y ago
  Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context. While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.
  - nicoburns 6y ago
    Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component. Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).
  - hackerfromthefu 6y ago
    and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate
    - nicoburns 6y ago
      > in the real world react apps use countless npm packages This is often the case in practice. But it's a pretty easy problem to avoid. Usually those packages simply aren't necessary in the first place.
  - hajile 6y ago
    If you use context, you'll just wind up rewriting flux, redux, Rx, Event, mobx, or whatever in what is likely a worse manner.
  - acemarke 6y ago
    I can assure you that Redux is not "dead" or "being abandoned": https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... https://blog.isquaredsoftware.com/2020/10/presentation-state-of-redux-2020/ https://blog.isquaredsoftware.com/2020/10/presentation-state... Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial: https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...
- wnevets 6y ago
  Can you run code written in 2015 on the latest version?
  - Izkata 6y ago
    Not necessarily; just offhand I remember these: https://reactjs.org/docs/react-component.html#legacy-lifecycle-methods https://reactjs.org/docs/react-component.html#legacy-lifecyc... Admittedly those are trivial renames, but they've been renamed as such because they're very likely to be buggy with async rendering.
- hackerfromthefu 6y ago
  bwahahahahahahahahaha
shams93 6y ago
Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.
- DarkWiiPlayer 6y ago
  That hardly makes any sense. Most widely used frameworks are open source projects; it seems much more reasonable to assume that constant changes in direction are more an expression of developers wanting to play with the fancy new toys instead of sticking with one paradigm and keeping it stable. Even setting that aside, there's nothing keeping older developers from switching to a newer technology; it might be a bit bothersome to adapt to ultimately inconsequential changes again and again, but that applies to younger devs just as much. It's also not like web development is old tech in any way. There's constant improvements being made and things are often changing for the better. Well, for the most part at least. Looking at the situation with serverside resource compilation I have to wonder when the world of web will re-invent make and call it a revolutionary achievement.
- X6S1x6Okd1st 6y ago
  That's a very strong statement, do you have anything to back that up?

nicoburns 6y ago

React has been stable since ~2015, and there are no signs of that changing.

madoublet 6y ago
I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
- NiceNamesOrg 6y ago
  Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
  - madoublet 6y ago
    My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.
  - onion2k 6y ago
    Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.
    - nicoburns 6y ago
      Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.
    - hackerfromthefu 6y ago
      But not all of your packages!
    - hatch_q 6y ago
      This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)
      - hajile 6y ago
        I did that migration on a very large react project (hundreds of thousands of lines). As I recall, after dealing with warnings for the later 15.x releases, the upgrade was seamless. They're also good about creating codemods to make the transition easier -- something somewhat rare in the world of software libraries.
  - hatch_q 6y ago
    I tried to upgrade a substantial codebase from vue 2 to 3 and hit a brick wall with Vuex early on.
JoeyJoJoJr 6y ago
I would say that the React ecosystem as a whole is in constant flux, which is what really matters.
- nicoburns 6y ago
  How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.
  - hackerfromthefu 6y ago
    As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant. React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s
    - nicoburns 6y ago
      > react apps often have dozens of additional packages. And the churn on these packages is significant. IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.
      - hackerfromthefu 6y ago
        I agree, for a significant portion of the packages yet not all. Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)
ryanbrunner 6y ago
I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it. Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.
- nicoburns 6y ago
  The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features). At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style. If you feel like you need to upgrade then I think that on you, not the framework.
- futureproofd 6y ago
  Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects. Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.
  - debaserab2 6y ago
    Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?
Cthulhu_ 6y ago
Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context. While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.
- nicoburns 6y ago
  Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component. Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).
- hackerfromthefu 6y ago
  and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate
  - nicoburns 6y ago
    > in the real world react apps use countless npm packages This is often the case in practice. But it's a pretty easy problem to avoid. Usually those packages simply aren't necessary in the first place.
- hajile 6y ago
  If you use context, you'll just wind up rewriting flux, redux, Rx, Event, mobx, or whatever in what is likely a worse manner.
- acemarke 6y ago
  I can assure you that Redux is not "dead" or "being abandoned": https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... https://blog.isquaredsoftware.com/2020/10/presentation-state-of-redux-2020/ https://blog.isquaredsoftware.com/2020/10/presentation-state... Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial: https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...
wnevets 6y ago
Can you run code written in 2015 on the latest version?
- Izkata 6y ago
  Not necessarily; just offhand I remember these: https://reactjs.org/docs/react-component.html#legacy-lifecycle-methods https://reactjs.org/docs/react-component.html#legacy-lifecyc... Admittedly those are trivial renames, but they've been renamed as such because they're very likely to be buggy with async rendering.
hackerfromthefu 6y ago
bwahahahahahahahahaha

shams93 6y ago

Organizations love the churn because they can get away with age discrimination lots of well qualified devs are left out to starve to death while constant churn hides a system designed to filter out the most experienced.

DarkWiiPlayer 6y ago
That hardly makes any sense. Most widely used frameworks are open source projects; it seems much more reasonable to assume that constant changes in direction are more an expression of developers wanting to play with the fancy new toys instead of sticking with one paradigm and keeping it stable. Even setting that aside, there's nothing keeping older developers from switching to a newer technology; it might be a bit bothersome to adapt to ultimately inconsequential changes again and again, but that applies to younger devs just as much. It's also not like web development is old tech in any way. There's constant improvements being made and things are often changing for the better. Well, for the most part at least. Looking at the situation with serverside resource compilation I have to wonder when the world of web will re-invent make and call it a revolutionary achievement.
X6S1x6Okd1st 6y ago
That's a very strong statement, do you have anything to back that up?