> You wouldn't know it from today's frontend discourse, but the modern era has never been without high-quality alternatives to React, Angular, Ember, and other legacy desktop-era frameworks.

"You wouldn't know it from today's frontend discourse"??? Seriously? Everybody and their dog know about those frameworks.

It feels like the first footnote was added in response to criticism from the reviewers of the drafts. It contradicts the body of the article and makes the whole thing incomprehensible.

The original article must have been a criticism of frontend frameworks in general. It points to the "sandy foundations" and frames all attempts at solutions as simply adding complexity - probably including all those new frameworks everybody talks about.

I mean yeah we know about them, but do we use them? Are we hiring for them?

Speaking as a front end dev who's been looking for a new role for the past 4 months... basically everyone wants 2-4 years of React experience. Every once in a while you see Angular, usually an older version, or Vue - very occasionally you'll see a "React or other modern framework" requirement.

React is the industry standard right now from where I'm standing. Yes we all know there are other things we could be using, but who's using them? (And are they hiring?)

I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought.

It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table...

And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...

Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages.

My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers.

If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to?

Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions.

Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man!

The senior eng team absolutely regrets going Next.js (decision made before I joined).

We've been fleeced.

> The senior eng team absolutely regrets going Next.js (decision made before I joined).

I am also late to a Next.js engineering party. It was chosen because hype but the developers had no experience in it so they were really just writing it like an SPA (actually no getStaticProps, no getServerSideProps, all client side fetching). The thing was/is a bit of a mess. I think the main problem for them was not taking the time to fully grok the server/client split and take advantage of it before diving in to implement features.

I used to dislike Next.js but it's grown on me considerably. Definitely has some problems. That said, I'm having a hard time imagining what this could possibly be:

> We have dozens of lines of code for what should take just a handful to do in vanilla.

> I used to dislike Next.js but it's grown on me considerably.

Give Astro.js a spin. Notably, take a critical eye to the HTML and JS output of Astro.js vs Next.js.

> I'm having a hard time imagining what this could possibly be

Think of something as simple as whether a div element is highlighted or not by simply adding/removing a CSS class name. In our case, it's a price tile like you'd see on Target.com. For this piece of functionality, there is a huge mountain of JS (also comprising the state) since we need to manipulate the object model to get the correct behavior when we conditionally render a class name. In vanilla, one might just do something like this and have a general purpose selection behavior:

    const $ = (selector) => document.querySelectorAll(selector)

    function select(evt) {
      $("li").forEach(li => li.className = "")
      evt.target.className = "selected"
    }

    $("li").forEach(li => li.addEventListener("click", select))

https://jsfiddle.net/84b5rhpk/2/

Another version with super simple option-detail selection: https://jsfiddle.net/84b5rhpk/3/

Even cleaner V3: https://jsfiddle.net/7szur3ex/

This code is incredibly fast; requires no compilation, it's highly reusable since it cross cuts the DOM structure using `querySelectorAll` (I can reuse this function to select anything), easy to understand, has no dependency on the underlying data model, and it is stupid easy to debug. A developer doesn't need to learn the quirks of a framework or library to do this.

You might make the case that "well, a lot more things are also happening when the user makes a selection", but I'd offer that almost all of the side effects would be easier with vanilla in our case.

Ah yeah, React doesn't make this any easier. You'll probably end up with a useState combined with className={clsx(selected[idx] && "selected")} or something. I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable. You'd have to box off the state to its own component to avoid re-rendering the entire list.

> I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable

It's not just the LoC,

    - I don't need a build chain for this; there's no transpilation.  
    - I don't need an external library to download to the client to do this.  
    - I can get the HTML from anywhere.  Rails, PHP, Node.js, ASP.NET, static bucket in S3.  Anywhere; I have more flexibility on my backend to pick something that's fast.  
    - It's incredibly fast in the browser and SEO friendly *without any extra work* because all of the HTML is already sitting there. 
    - I didn't need any rehydration or complex data flow/data passing logic from server to client.  
    - It's easily debuggable even in production

An even cleaner version:

https://jsfiddle.net/7szur3ex/

This is like 95% of the interactivity needed on an e-commerce PDP in 15 lines of JavaScript.

You might be moving the goalposts slightly. The original comment said there were things you can do in a handful of lines in vanilla that it takes dozens of lines of React because you were concerned about complexity. Setting up the project should not be part of that complaint [if you guys have to set up the project every time you try to add a class to a selected item, I can understand why that would be cumbersome ;) ]. Vanilla JS tool chains being comparitively less complex and emitting smaller builds is not the line of discussion I thought I was engaging.

You don't have to set it up every time, but many features require that you tweak the setup and/or migrate your setup/configuration. I can't imagine having to tweak <script src="..." />

Rather than moving the goal posts, I'd proffer that you are missing the forest for the trees.

Case in point: Next 12 to Next 13. The architecture of layout pages, client vs server only components, new build chain (surely will have its own kinks and bugs to iron out). Then there will be a Next 14, TurboPack 2, React 19, etc. Migrating some remaining systems from Node 12/14 to Node 16/18 and updating our CI configurations, local dev environments, and praying that all the packages update without issue. Breaking changes in upstream NPM packages. React's shift from class components to functional components and hooks. Working on integrating InstantSearch into a Next.js app this week and the `useClearRefinements` hook can't be included on the server side (despite the fact that our SSR is broken right now). So I needed to use `next/dynamic` and exclude it from SSR to get it to build which seemed extra ridiculous because...

As I mentioned, this week, I noticed that our SSR pages were suddenly no longer generating any HTML on the server essentially turning our Next app into a full CSR app with server side API calls. I checked in with CTO and FE dev to see if this is intentional or accidental. Something errant with the toolchain, configuration, or change in how we are loading assets is now causing Next to misbehave (haven't figured this one out yet).

I will never, ever have to deal with this with those 15 lines of JS. Those 15 lines of JS will never need to be migrated into a different runtime, build process, tool chain, or stack. 10 years later, those 15 lines of JS are still going to work. Whatever migrations you need to do to modernize your toolchain and stack over the next two years is work and effort that you're not spending on creating value.

So the tool chain creates its own complexity that is secondary to the core development complexity. That's Alex Russell's point in the article: the complexity merchants have created an environment where there's so much unnecessary complexity and -- wouldn't you guess it? -- they have just the thing you need to solve it! They have you on a treadmill while they're feeding you doughnuts and chocolate.

Okay, I'm just saying this isn't the conversation I signed up for. I've heard people scream about react and tool chains and how much they hate js pretty much nonstop since I've been a user of this site. I am not interested. If I thought it would go this way, I wouldn't have engaged you.

Haha, I hope you don't feel attacked; apologies if it comes across that way. I am right with you on that treadmill and really appreciate the discussion and counter-perspective to help me think through my own. If anything, this interaction has helped me clear some fog around our stack so I appreciate that you were willing to engage in a discussion.

Cheers!