3 ms·

They are very much counter arguments to the idea that there is big churn still happening. Webpack 2 was in CRA in 2017 Redux and MobX have been the #1 and #2

by nawgz 4y ago

They are very much counter arguments to the idea that there is big churn still happening. Webpack 2 was in CRA in 2017 Redux and MobX have been the #1 and #2 state managements for that whole span, and clearly all the observable libs are successors of MobX after Proxy came out Every language changes, many with breaking version changed that JS avoids I don’t know how you’d point at package management as an issue in JS land It’s just that every single popular community has massive amounts of clones or similar libraries, I don’t know how that qualifies as “churn” though. I maintain my 2017 apps including major version bumps with no issues today, using the same libraries and tools. The argument you’re making was fine in 2016 but is half a decade out of date.

ricardobeat 4y ago
> I maintain my 2017 apps including major version bumps with no issues today Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”. Webpack alone has gone through five major revisions in this time, with large breaking changes meaning all of your plugins and babel extensions needed upgrading (sometimes not readily available), rewriting the entire config, even before you get to upgrade React and dependencies. React Native has changed massively in this timeframe, I’m talking complete API refactoring and packages moving around, not simple function signature changes. This is simply not reality for people working tech jobs. For a glaring example, you say it’s #1, but Redux is dead in the water. I haven’t interviewed a single person in the past two years that wants to use it. The creators have been recommending “just using react.Context” for years and that has clearly had an effect.
- nawgz 4y ago
  > > I maintain my 2017 apps including major version bumps with no issues today > Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps” What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX 6. I of course had to update some babel configurations but it was much more version bumping than configuration rebuilding. It still uses decorators and looks like complete dog-shit, and that's my point: the same tricks and patterns available then are not only there, but working identically now. Re: native, I don't believe in React Native or any webview-based "native" replacement anyways, but it's easy to do this as my user-base is interacting with this app from their company-provided laptops anyways. I would willingly concede React Native is an environment with churn, I don't really recall RN every reaching meaningful stability > Redux is dead in the water https://www.npmjs.com/package/redux https://www.npmjs.com/package/redux shows 7M downloads weekly https://www.npmjs.com/package/react-redux https://www.npmjs.com/package/react-redux shows 5M https://www.npmjs.com/package/@reduxjs/toolkit https://www.npmjs.com/package/@reduxjs/toolkit shows 1.5M MobX / MobX React are around 1M/700k Your list of "flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai" seems to peak at 500k with the exception of "react-query", which I don't really see as applicable to a conversation about state management. Overall, this list perfectly illustrates my point that there's new stuff but you don't need to know it, and the value props aren't convincing alive-and-well shops to drop everything and rebuild > you say it’s #1, but Redux is dead in the water I never personally believed in Redux, it struck me as a terrible pattern from the start, thus why I selected MobX; but I find it difficult to believe that you really think React Context scales the same way building an external state management tree does. I like React Context, but it doesn't do a very good job of hiding away complexity from the developer as the application grows. Not to mention it does no render-optimization for you. Again, I'm not saying things don't change or that there's not alternatives, but I am saying that someone who learned fundamentals in 2017 is still able to get up-to-speed in the updated versions of the library kings of 2017 in virtually no time, and deliver standard-fare webapps. I say this because I've worked at the same place for over 5 years, I use the same tools, and my users regularly are telling me the tools my team puts in front of them are the gold standard. The churn is long gone, everything you describe would have perfect analogues in any other popular modern language / library ecosystem.
  - ricardobeat 4y ago
    > I find it difficult to believe that you really think React Context scales the same way I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons. jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption. I've been involved in multiple new product development efforts in the last decade, and can tell you it looks a lot different from maintaining one stable product. And it's sped up by 10x if work at an agency putting out a different project every 2-3 weeks. This is where the fatigue comes from.
    - nawgz 4y ago
      Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago
      - ricardobeat 4y ago
        You said 'It's a React/MobX collaborative model editing internal tool' so I assumed you're commenting based on that particular project. It's not a value judgement either way. The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.
        nawgz 4y ago
        Yes, this whole time you’re assuming I’m doing the bare minimum, and that no one could be using the same tools. Yet, here I am, new apps in hooks based react, old ones not, and the same stack delivering great performance in either case - DX is only suitable in some tho I’ve used Context only, SolidJS, Angular, whatever you like these days, I still would only build real apps with MobX. Typescript is the only real change since 2017 you need, otherwise what’s newer is not what’s better since then. That’s the point. Take care and try to not get lost in the noise, it’s very different than what came before it

by nawgz 4y ago

ricardobeat 4y ago

> I maintain my 2017 apps including major version bumps with no issues today Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”. Webpack alone has gone through five major revisions in this time, with large breaking changes meaning all of your plugins and babel extensions needed upgrading (sometimes not readily available), rewriting the entire config, even before you get to upgrade React and dependencies. React Native has changed massively in this timeframe, I’m talking complete API refactoring and packages moving around, not simple function signature changes. This is simply not reality for people working tech jobs. For a glaring example, you say it’s #1, but Redux is dead in the water. I haven’t interviewed a single person in the past two years that wants to use it. The creators have been recommending “just using react.Context” for years and that has clearly had an effect.

nawgz 4y ago
> > I maintain my 2017 apps including major version bumps with no issues today > Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps” What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX 6. I of course had to update some babel configurations but it was much more version bumping than configuration rebuilding. It still uses decorators and looks like complete dog-shit, and that's my point: the same tricks and patterns available then are not only there, but working identically now. Re: native, I don't believe in React Native or any webview-based "native" replacement anyways, but it's easy to do this as my user-base is interacting with this app from their company-provided laptops anyways. I would willingly concede React Native is an environment with churn, I don't really recall RN every reaching meaningful stability > Redux is dead in the water https://www.npmjs.com/package/redux https://www.npmjs.com/package/redux shows 7M downloads weekly https://www.npmjs.com/package/react-redux https://www.npmjs.com/package/react-redux shows 5M https://www.npmjs.com/package/@reduxjs/toolkit https://www.npmjs.com/package/@reduxjs/toolkit shows 1.5M MobX / MobX React are around 1M/700k Your list of "flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai" seems to peak at 500k with the exception of "react-query", which I don't really see as applicable to a conversation about state management. Overall, this list perfectly illustrates my point that there's new stuff but you don't need to know it, and the value props aren't convincing alive-and-well shops to drop everything and rebuild > you say it’s #1, but Redux is dead in the water I never personally believed in Redux, it struck me as a terrible pattern from the start, thus why I selected MobX; but I find it difficult to believe that you really think React Context scales the same way building an external state management tree does. I like React Context, but it doesn't do a very good job of hiding away complexity from the developer as the application grows. Not to mention it does no render-optimization for you. Again, I'm not saying things don't change or that there's not alternatives, but I am saying that someone who learned fundamentals in 2017 is still able to get up-to-speed in the updated versions of the library kings of 2017 in virtually no time, and deliver standard-fare webapps. I say this because I've worked at the same place for over 5 years, I use the same tools, and my users regularly are telling me the tools my team puts in front of them are the gold standard. The churn is long gone, everything you describe would have perfect analogues in any other popular modern language / library ecosystem.
- ricardobeat 4y ago
  > I find it difficult to believe that you really think React Context scales the same way I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons. jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption. I've been involved in multiple new product development efforts in the last decade, and can tell you it looks a lot different from maintaining one stable product. And it's sped up by 10x if work at an agency putting out a different project every 2-3 weeks. This is where the fatigue comes from.
  - nawgz 4y ago
    Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago
    - ricardobeat 4y ago
      You said 'It's a React/MobX collaborative model editing internal tool' so I assumed you're commenting based on that particular project. It's not a value judgement either way. The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.
      - nawgz 4y ago
        Yes, this whole time you’re assuming I’m doing the bare minimum, and that no one could be using the same tools. Yet, here I am, new apps in hooks based react, old ones not, and the same stack delivering great performance in either case - DX is only suitable in some tho I’ve used Context only, SolidJS, Angular, whatever you like these days, I still would only build real apps with MobX. Typescript is the only real change since 2017 you need, otherwise what’s newer is not what’s better since then. That’s the point. Take care and try to not get lost in the noise, it’s very different than what came before it