5 ms·

You covered the frameworks, but a lot of the feeling comes from the tooling and library ecosystem. For example, a recap of the last 10 years: - grunt / broccol

You covered the frameworks, but a lot of the feeling comes from the tooling and library ecosystem. For example, a recap of the last 10 years: - grunt / broccoli / gulp / browserify / webpack / metro / esbuild / parcel / swc / turborepo / bun - flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai And this is just within React, and off the top of my head. Then you add all the ECMAScript versions, browser feature churn, node.js, npm/yarn, immutability, classes, functional components, hooks, fiber, the list goes on and on.

nawgz 4y ago
Webpack has been the de facto build system for react since 2017 Competing state libraries is to be expected but picking redux or mobx has let you use the same ones since 2017 JS itself has improved but hasn’t really ever deprecated anything, it just grows and adds terse methods to the language Npm and yarn are among the best package managers React hooks were the only major change you’ve touched on but even they didn’t deprecate class based react or change library semantics very significantly
- abraxas 4y ago
  > Webpack has been the de facto build system for react since 2017 lol and that's why we saw the emergence of rollup and parcel and snowpack and whatever the hell else came along since then?
  - nawgz 4y ago
    I’ve never seen a situation where someone hasn’t tried to rebuild something that’s already working (in a big community like JS land). Some people wanted more performance from their build systems, some people like other languages to do the transpilation, some people thought the configuration options were too heavy and opaque. That’s why we saw ESBuild and rollup. But CRA is still on webpack, and CRA is still the de facto default way to make a new react app. I don’t really see the fact that alternatives exist as implying churn when the same option has been the longest living and most popular.
- ricardobeat 4y ago
  These are not really counterarguments to the fact that things change a lot here, and newcomers and veterans alike need to continuously learn, and pick the best. None of these started off as the default choice, I remember when each and every one of these was the weird / risky option.
  - 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.
thepasswordis 4y ago
Just to chime in here for anybody reading along: I work full time as a software developer doing react. I have got literally no idea what almost everything you listed is. "Broccoli"? I have heard: grunt, gulp, webpack, metro, redux, and recoil. The rest of those could be sarcasm for all I know.
- meowtimemania 4y ago
  Broccoli I believe is still used to build ember projects
- ricardobeat 4y ago
  These are only the mainstream ones I can remember, there have been a ton more! I guess if you've started post-2018 things have been a bit more stable, but there was quite a bit of churn to get here. And it's still happening - no two React projects are alike even in the enterprise. https://github.com/broccolijs/broccoli https://github.com/broccolijs/broccoli
  - mccorrinall 4y ago
    That’s because react is a library, and not a framework. React doesn’t have opinions, that’s why you can find 300 state management libraries and 200 routers which do the same thing, just in different ways.
    - throw_m239339 4y ago
      > That’s because react is a library, and not a framework. React should be considered a framework. React absolutely imposes a data model (unidirectional workflow) to the developer thus a certain code structure. The fact that it is light weight compared to Angular doesn't change the fact that React is a front end framework. React usage completely replaces the traditional way to interact with the DOM and manage DOM events, thus abstracting it. > React doesn’t have opinions, React becomes very hard to use if your data model isn't organized to suit React architecture. It doesn't have opinions about everything (like AJAX or SPA routing) but it absolutely has an opinion about how you data objects should be structured.
cehrlich 4y ago
It’s true that there are a lot of different ways to do the same thing, but the good news is you’re doing the same thing and the difference is mostly just syntax. Someone who has used Redux extensively can get up and running with Zustand in no time, and vice versa. Likewise React Query and Apollo Client are basically the same thing. Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.
- msie 4y ago
  As if it's so easy to move from one thing to another. Yikes!
  - azemetre 4y ago
    Some libraries will create code mods to assist in transitions. For example I've used some MUI codemods in the past to make transitions to newer versions of the library more seamless [1]. There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment). ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against. [1] https://github.com/mui/material-ui/blob/master/packages/mui-codemod/README.md https://github.com/mui/material-ui/blob/master/packages/mui-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree https://en.wikipedia.org/wiki/Abstract_syntax_tree
korm 4y ago
I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us. Anyone who feels compelled to jump from one unproven state management library or bundler to another, in serious projects, is just not doing their due diligence.
- scrose 4y ago
  > I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us. Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.
  - korm 4y ago
    Yes to both, and I can't say many projects followed a radically different approach, at least without good reason. Webpack and Redux for example are many times more common than something like Parcel or Jotai, so it's rare to encounter many of these alternatives in one project.
  - Hermitian909 4y ago
    > that's rare, but great Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.
madeofpalk 4y ago
Postgres, mysql, mariadb, cockroachdb, Prometheus, neo4j, firebase, dbaas. The list goes on and on. Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.
- jhgb 4y ago
  There's people out there who chose PostgreSQL twenty five years ago and found out since to have made the right choice. Not sure if that can be said of any item on the list you were responding to.
- Shalomboy 4y ago
  I would be thrilled to work someplace that uses neo4j. Such a good graph dbms. Too many folks believe the only way to organize data is with relational tables.
5350-uiop-1130 4y ago
and now its all use Deno and Svelte bro. 6 months it will be you're still using Deno and Svelte, should be using XDenoX and ReSvelte (or something).

nawgz 4y ago

Webpack has been the de facto build system for react since 2017 Competing state libraries is to be expected but picking redux or mobx has let you use the same ones since 2017 JS itself has improved but hasn’t really ever deprecated anything, it just grows and adds terse methods to the language Npm and yarn are among the best package managers React hooks were the only major change you’ve touched on but even they didn’t deprecate class based react or change library semantics very significantly

abraxas 4y ago
> Webpack has been the de facto build system for react since 2017 lol and that's why we saw the emergence of rollup and parcel and snowpack and whatever the hell else came along since then?
- nawgz 4y ago
  I’ve never seen a situation where someone hasn’t tried to rebuild something that’s already working (in a big community like JS land). Some people wanted more performance from their build systems, some people like other languages to do the transpilation, some people thought the configuration options were too heavy and opaque. That’s why we saw ESBuild and rollup. But CRA is still on webpack, and CRA is still the de facto default way to make a new react app. I don’t really see the fact that alternatives exist as implying churn when the same option has been the longest living and most popular.
ricardobeat 4y ago
These are not really counterarguments to the fact that things change a lot here, and newcomers and veterans alike need to continuously learn, and pick the best. None of these started off as the default choice, I remember when each and every one of these was the weird / risky option.
- 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.

thepasswordis 4y ago

Just to chime in here for anybody reading along: I work full time as a software developer doing react. I have got literally no idea what almost everything you listed is. "Broccoli"? I have heard: grunt, gulp, webpack, metro, redux, and recoil. The rest of those could be sarcasm for all I know.

meowtimemania 4y ago
Broccoli I believe is still used to build ember projects
ricardobeat 4y ago
These are only the mainstream ones I can remember, there have been a ton more! I guess if you've started post-2018 things have been a bit more stable, but there was quite a bit of churn to get here. And it's still happening - no two React projects are alike even in the enterprise. https://github.com/broccolijs/broccoli https://github.com/broccolijs/broccoli
- mccorrinall 4y ago
  That’s because react is a library, and not a framework. React doesn’t have opinions, that’s why you can find 300 state management libraries and 200 routers which do the same thing, just in different ways.
  - throw_m239339 4y ago
    > That’s because react is a library, and not a framework. React should be considered a framework. React absolutely imposes a data model (unidirectional workflow) to the developer thus a certain code structure. The fact that it is light weight compared to Angular doesn't change the fact that React is a front end framework. React usage completely replaces the traditional way to interact with the DOM and manage DOM events, thus abstracting it. > React doesn’t have opinions, React becomes very hard to use if your data model isn't organized to suit React architecture. It doesn't have opinions about everything (like AJAX or SPA routing) but it absolutely has an opinion about how you data objects should be structured.

cehrlich 4y ago

It’s true that there are a lot of different ways to do the same thing, but the good news is you’re doing the same thing and the difference is mostly just syntax. Someone who has used Redux extensively can get up and running with Zustand in no time, and vice versa. Likewise React Query and Apollo Client are basically the same thing. Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.

msie 4y ago
As if it's so easy to move from one thing to another. Yikes!
- azemetre 4y ago
  Some libraries will create code mods to assist in transitions. For example I've used some MUI codemods in the past to make transitions to newer versions of the library more seamless [1]. There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment). ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against. [1] https://github.com/mui/material-ui/blob/master/packages/mui-codemod/README.md https://github.com/mui/material-ui/blob/master/packages/mui-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree https://en.wikipedia.org/wiki/Abstract_syntax_tree

korm 4y ago

I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us. Anyone who feels compelled to jump from one unproven state management library or bundler to another, in serious projects, is just not doing their due diligence.

scrose 4y ago
> I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us. Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.
- korm 4y ago
  Yes to both, and I can't say many projects followed a radically different approach, at least without good reason. Webpack and Redux for example are many times more common than something like Parcel or Jotai, so it's rare to encounter many of these alternatives in one project.
- Hermitian909 4y ago
  > that's rare, but great Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.

madeofpalk 4y ago

Postgres, mysql, mariadb, cockroachdb, Prometheus, neo4j, firebase, dbaas. The list goes on and on. Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.

jhgb 4y ago
There's people out there who chose PostgreSQL twenty five years ago and found out since to have made the right choice. Not sure if that can be said of any item on the list you were responding to.
Shalomboy 4y ago
I would be thrilled to work someplace that uses neo4j. Such a good graph dbms. Too many folks believe the only way to organize data is with relational tables.

5350-uiop-1130 4y ago

and now its all use Deno and Svelte bro. 6 months it will be you're still using Deno and Svelte, should be using XDenoX and ReSvelte (or something).