I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.
- 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.
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
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.
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.
> 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 shows 7M downloads weekly
https://www.npmjs.com/package/react-redux shows 5M
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.
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.
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.
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
lol and that's why we saw the emergence of rollup and parcel and snowpack and whatever the hell else came along since then?
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.
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.
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.
Literally on the start page
It's probably cause I switched 4 years ago from the typical perma-migration grind to rarely using any framework and coding JS like I code the backend. Simple service classes in pure JS, rare dependencies, simple build. I once ditched years of work by a team of 40 to rewrite "everything" in low level javascript and showed the guys that what we spent all this years writing, really, was useless: did we need that enormous angular runtime config resolver that would draw generic components reading from crafted json configuration ? Or could we just write the damn things as we mean it in... javascript directly ?
Don't use a JS framework as long as you can help it, just the simple fact you can trace the whole function chain in a few seconds, vs reverse engineering the damn VueJS, or React, or Angular (does that monster even exist anymore, we hear about it a lot less than when it was all-encompassing, 8 years ago) plumbing, is worth it.
And son, if you want some war stories from your granddad, have you heard of jQuery ? :D
> if you want some war stories from your granddad, have you heard of jQuery ? :D
Bah, whippernsapper! I cut my baby web teeth on CGI and spent the bulk of it in Struts and JSF. Remember THOSE?
However, employers dont need to be involved in choosing a framework or not. You ll notice that usually its the little bees building their resumes that bemoan non stop about migrating from react to vue or vue to react :D
I never heard a sales guy tell me: WHAT, it works fine, is cheap to maintain and has no stupid 10k levels dependency graph in npm ? I ll stop making money on this until you completely "standardize" it into a moving sand on npm. And dont forget a pipeline of 3 transpilers, you wouldnt want to write in a browser-native language, caveman.
I do use requireJS to split in nice files and import easily though I admit.
Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.
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-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree
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.
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.
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.
Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.
> I no longer think front-end suffers the instability people accuse it of.
Do you mind elaborating why you believe this is the case?
now that it is 2022, what's the new flavor that would be prescient? I don't ask to actually know, but to reiterate the problem of nothing being solid in this world.
(Now what you couple with NextJS for data access is an interesting question - this is where there's a lot of innovation. Personally, I'm going with tRPC. I would look at Edge DB, but in this application I'll need a recursive CTE and Edge can't do it.)
Edit: I do think Astro might replace NextJS for purely-static sites, or ones where the "islands of interactivity" pattern is compelling.