Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
Material UI
Ready-to-use foundational React components, free forever. It includes Material UI, which implements Google's Material Design.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
the last good ideas in js land were react and google’s closure compiler.
reagent[1], a react wrapper, has had a stable and tiny api for a decade.
easy, fun, and effective sdlc[2] on mature technology is easier now than ever.
there are no more excuses.
1. https://reagent-project.github.io/
2. https://github.com/nathants/new-gocljs
the last good ideas in js land were react and google’s closure compiler.
reagent[1], a react wrapper, has had a stable and tiny api for a decade.
easy, fun, and effective sdlc[2] on mature technology is easier now than ever.
there are no more excuses.
1. https://reagent-project.github.io/
2. https://github.com/nathants/new-gocljs
> > 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 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, and perfectly illustrates my point that there's new stuff but you don't need to know it
> 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 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 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, and perfectly illustrates my point that there's new stuff but you don't need to know it
> 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.
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-...