I've worked on webapps that are part jquery, part classic angular, part react, and part angularjs.

My opinion of each of those parts has been primarily down to the developers, not the underlying choice of framework.

Things that work in production last.

jQuery has faded into the background, no longer interesting.

React has too many sharp edges, it'll only be here until something shinier supercedes it.

> jQuery has faded into the background, no longer interesting.

It’s a mature, stable technology, still in wide use - and not really a competitor with react. That you claim it’s “no longer interesting” says more about your own preferences and ironically makes it sound that you are personally interested in the newest shiny fads - so I’m confused, what is your objection to react then?

Angular isn’t exactly dead - and is a more apt comparison.

I’m currently job searching and actually came across several mentions of jquery in job descriptions. It’s still alive!

Edit: 3,700,000 downloads per week on npm alone. That’s not a complete or perfect representation of usage, but that’s a significant number

What else do you need jQuery for? The most important parts are already included in the browser.

Honestly I bet a significant portion of the code I have maintained (and even some I’ve written) was reinventing a wheel someone didn’t know existed. Not even out of a desire to solve a problem, but simply not realizing it was done already.

I suspect people still reach for jquery for similar reasons. They know it makes complicated stuff work, it’s reliable, they don’t need to think about the specifics of the problems it solves… As a result, they’re less likely to discover that it’s no longer necessary in the first place. They’ll just keep using it.

The same will happen to react. React will become a victim of its success, because the more it is used the more likely its concepts will be integrated directly into the browser or ECMAScript

Maybe this is less obvious if you’re deep in the React ecosystem and nothing else but I’d argue that React is already in early stages of a death spiral for a few reasons.

These mostly come down to

1. It’s no longer the fastest, in fact it’s barely competitive speed wise with many things that have come after it.

2. It’s architectured in such a way that it is fundamentally misaligned with the rest of many web standards (I.e the DOM) which made a lot of sense when it was released but is now a major liability.

3. It now has to ship around a lot of code that now lives natively inside the browser and is now rather bloated as a result compared to newer iterations such as Lit as mentioned in the article.

Personally, I think it’s fatal in the sense that they have painted themselves into a very specific corner with no obvious engineering solution to get them back on the standards path. Its problems as a result aren’t really fixable without major architectural changes that would fundamentally change the project. On top of that they are only going to get actively worse over time as more things get moved into the browser and they are still stuck shipping a bunch of JS code to do the same thing. In short they are on a bad long term path with no clear off ramp.

I wouldn’t start a major project in React in 2022 for something I wanted to be around in 5 years from now as a result.

Never said I wasn't partial to shiny.

jQuery was and continues to be just about as successful as it is possible for a project to be. The reason it’s no longer as widely used is because it essentially became part of the platform. Most of what jQuery does is now possible with platform APIs, and those APIs exist mostly thanks to jQuery proving their utility.

A similar thing happened to CoffeeScript: no one uses it anymore because nearly all of its good ideas made their way into JavaScript itself.

What sharp edges? (This is an honest, curious question.)

I don't find many sharp edges in day-to-day React work. I say this having once been a very strong proponent of framework-less frontends, before trying Vue, then Svelte, and then settling on React.

Does React itself have edges, or do your issues derive from other parts of the ecosystem (Redux, styled-components, MobX, whatever)?

React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework.

And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be.

Now, do I still use React for everything? Yes. Do I prefer hooks to class components? Also, yes.

> Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework.

Okay I can criticize React and its weird solutions until the cows come home, but this is a pretty weird one because it’s entirely an implementation detail. No one working with Suspense ever needs to know that’s how it works unless they’re building a library to be compatible with its behavior. Otherwise it’s just trivia.

Wouldn't the debugger break on exception? So any exceptions used in "nonexceptional" situations have a potential to "pollute" the debugging experience?

Admittedly, I haven't tried debugging React 18 yet, so I don't know if that actually happens in practice.

Only if you set it to break on handled exceptions/Promise rejections. This isn’t new behavior in React 18, it’s been the mechanism used for Suspense since it was introduced. If you have used Suspense and haven’t had unexpected debugger pauses, that’s what you should expect going forward.

I work primarily with React, and I'm curious - why do you consider hooks to be an anti-pattern? (This isn't a criticism, genuine curiosity)

In practice, because they don't work the way most people think they work, and because it's really easy to screw up using them.

Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.

For example, if I have

    const a = useRef(true);
    const b = useRef(false);

The only way react knows that the first value it should return the next time it renders is what I'm expecting to be value `a` is because that useRef is called first every render. These are all kinds of rules and assumptions about hooks that make them not behave at all like normal functions. I don't think people understand that, for useRef, for example, those two lines of code are run every render, passing in the initial starting values, which then react disregards after the initial render, and maintains a mapping of ref and state and memo etc values all by the order the hooks are called in. I see people use hooks in callbacks all of the time and just fundamentally not understand that they're doing it wrong.

Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.

And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.

I don't like them because they hide program state in innocuous-seeming function calls. Want to call useContext in a helper? It'll work, until it doesn't. Want to display a loading spinner? You'd better not have any useState calls below it. Want to see what hooks a function will use? You have to run it or go through each line of every piece of code it calls, they're not in any way declarative.

The programming paradigms I like best are declarative and make invalid or undefined behaviour impossible to represent. Hooks do the opposite: they're procedural, make it very easy to write a program that compiles with subtle errors, and don't have compile time checks to stop bad code.