My position isn't that we should be using a new library per se. It's that we should be more selective about what 3rd party code we use and espescially what we ship to end users. React has tended towards a kitchen sink approach and this is exacerbated by initial design shortcomings/decisions i.e. no built in state management or method for encapsulating styles has lead to a deluge of libraries that promise to fill the gaps, none of which quite work with one another. This I guess is why we've seen the rise of meta-frameworks like Next which fill this gaps in a predictable way. But these just meta frameworks just shift developers another step further from the underlying HTML/CSS/JS making it harder to debug things and harder to fix issues when you stray from the framework's happy path.

(All that said, I don't blame people for choosing React for certain classes of projects, the economics of hiring new devs, the relative maturity and stability , the large community etc all make for powerful incentives to choose React)

Wait react is a kitchen sink approach but in the same breath you said it doesn't come with everything. Do you mean tended away?

Sorry, reading this back I see where that might be confusing. It's a few days later now but I think I was referring to React in the round as deployed in the real world, the community norms etc. rather than just the core library. In my experience the way that React projects tend to develop is that "tried and tested" libraries get added to to solve particular issues, most commonly state and styling (codified in meta-frameorks like NextJS etc.) but also UI transitions, wrappers around common non-react libraries like Leaflet or threeJS etc. The reason being that it's actually quite hard to sensibly integrate vanila JS libraries into a React code base so if someone has done the hard work why would you not use that. But of course this comes at a cost. More recent libraries (in my experience svelte but i understand this is a common feature) mitigate the issue by 1. having a builtin approach to state and styling 2. making it easier to drop down to the underlying HTML/CSS/JS without making a mess.

> It's easy to hire people, onboard people

Yes they'll know the React part. It's the Redux/Mobx/React Router/whatever snowflake libraries you chose part that will be more difficult. I really don't like incomplete solutions personally.

Well, don't use those. Pure React is enough 95% of the time, and then an additional 4.9% can be handled with jotai in a couple of places.

React + GraphQL + jotai is my preferred stack

> Don't use those...then an additional 4.9% can be handled with jotai...

Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.

I agree with you about routing. Something so core about building web apps should be treated as a first class citizen of the ecosystem.

I don't think jotai adds a lot of complexity though, and like I said most of the time you don't need it. It just makes syntax a bit nicer to read and write, but you could do it with context if you really wanted to.

Jotai is literally like a single file.

Here's a video on how to use Jotai by writing your own in minutes: https://youtu.be/gg31JTZmFUw

Jotai may be small and focused, but is definitely not a single file: https://github.com/pmndrs/jotai/tree/main/src/

Yes, sorry my bad, the project isn't a single file. I was just talking about the implementation.

They intentionally didn't provided that to let the ecosystem explore different solutions.

Its all about preferences, I tend to prefer seasoned devs who have had the chance to try different things and form their own opinions. Someone who has relied on framework magic they don't understand through their careers tend to be less resilient to change

Why do you assume they do not understand the single framework "magic" yet others do understand React's ecosystem?

>Redux/Mobx/React Router

All of these libraries are standard and easy to approach; when I was freelancing, my onboarding on React projects was incredibly quick, and I pushed bug fixes and features within the first few hours of joining a project. React's productivity boost is often overlooked; most developers should easily understand a fairly well-written React component connected to a Redux store.

I would like if the industry had less React domination. React is a bit like the IE8 of frameworks. It might not be the best choice for individual cases, but you have to learn its quirks as a developper since all the industry uses it.

But if we don't replace it, I appreciate if React introduced fine-grained updates and changed their attitude towards performance. I think as an industry, we have been pushing the "optimization is the root of all evil" statement beyond it's limits and now all software is super slow (except maybe games and some nice things like Excalidraw).

As I'm writing this, I noticed that Excalidraw uses React, so I wonder what's their secret sauce. Maybe recoil?

  People laugh at web development, especially the frontend, for changing libraries every week

that's a 2016 meme. Things have been remarkable stable since.

Except React decided to change to hooks and break all their docs. And Vue decided to break things with ver 3. And then there's Next. No, Nuxt. Wait, no, it's Nest. Or Sveltekit. It's not frontend anymore, it's more like frontend on backend, but not quite. No, is both now, we got interactive islands. And web components. Oh and wasm. Or was it blazor? And we have webpack. No, Vite. Or Parcel? Almost forgot, it's esbuild this week, innit?

But other than that, yes, frontend is pretty stable now.

I mean, that's just a laundry list of buzzwords. Yes, these are all things that exist, but that doesn't mean anyone has to learn them or that they're even used in a significant number of real-world codebases. It's like complaining about web development in Python, because there was Django, then Flask, Bottle, CherryPy, and now FastAPI, or Starlette, or Starlite, and Pydantic or attrs or dataclasses or whatever else. In practice, there are some fairly clear ecosystem best practices for the majority of cases, and a bunch of different alternatives because every ecosystem loves trying out different ways of doing things.

I think you've accidentally proven his point. Half the things you've mentioned have been around for half a decade at this point, and pretty much all of them have existed for at least 2+ years.

Frontend is still a fast moving space with a large ecosystem - and I get for some, that's not ideal. But this 'frontend fads' meme isn't really reflective of the current reality.

Webpack - 2012, Next - 2016, Nuxt - 2016, Nest - 2017, Parcel - 2018, Blazor - 2018, React Hooks - 2019, Vite - 2020, Vue 3 - 2020, ESBuild - 2020, Sveltekit - 2020

Rust, which is the greatest new hotness in the backend world is from 2015.

Other major languages in the backend world are at least 2 decades old (C#, Java, Python, C++, Ruby, etc).

C# with the .Net framework is an interesting example. Microsoft realized their original windows only approach was a dead end. They created .Net Core. But someone moving from .Net framework to .Net core didn’t have to relearn much at all, beyond initial config/bootstrapping, and which subset of the APIs had been implemented, because MS completed the implementation in stages.

On the flip side you have React, where you’re ostensibly using the same library for a decade, except halfway in between they made a change which completely flipped how developers weee supposed to use the library.

The claim that if you used React for the past 6 years meant you used a single library is almost certainly false.

Because what React is as a library today, with functional components+hooks is completely different from what React was when it first came out, with class components.

React is quite clearly a name that incorporates at least 2 distinct libraries which are supposed to be fully compatible but they’re not…try using a ref for a functional component.

The existence of these 2 libraries under the same name means thst documentation is also increasingly confusing. It also means that both libraries are probably making compromises So they’re still compatible with each other on the surface.