React in 2022

Big kickback against React this week (and the past cuppla weeks), surrounding confusion about useEffect, double rendering, and performance, especially vs. "traditional" multi-page applications. In particular, Taylor Hunt's series on trying to speed up web applications at American grocery chain Kroger.

The upshot of all of this discourse is: React is slow by default; React's abstractions don't work the way that you think they do; React developers usually aren't acquainted with the underlying JavaScript, which feeds back into the first two.

I'm surprised that this is only coming up now, because this has been the case for years. Next.js and Vercel have done a lot of credit to the React ecosystem, but the React approach to software development on the web is hype-driven and maximalist—in fact, a lot of JavaScript development is.

There are two schools of thought weighing in on solutions: the first advocates learning the JavaScript fundamentals and shipping only as much JavaScript to the client as needed; the other advocates swapping out React for another framework that avoids React's pitfalls, like Solid or Svelte—whichever gets the more hype.

I fall into the former camp—a JavaScript framework isn't remotely needed for 90% of use cases (like this site, running needlessly on Next.js). But developers will continue to learn and use React because that's where the money is. Vocal developers on Twitter are trying to make the world a more user-friendly, accessible place, but the silent majority just wants to get paid. The good news is that falling back on the fundamentals of JavaScript, and having a good understanding of component-based architectures, is enough to get almost any JavaScript-oriented job. JavaScript web frameworks are dead, long live JavaScript web frameworks.

So what? by Taylor Hunt

Web Code

Next

jdan's hashart

Jordan Scales's online SHA-256-based generative art project has me wanting to generate some art of my own.