Do Frameworks Matter Anymore?

I'm not trying to be facetious. I really want consider whether or not, in 2026, in the age of vibe coding, agentic programming, loop or graph or whatever diagrammatic metaphor-based engineering is most popular, does it matters what web framework you use? More importantly (to me and my particular interests), and at the risk of Betteridge-ing myself: should we make new frameworks?

React won, so do we ever try anything new?

Is there now just more room for niches? Nobody cares about the implementation details. Nobody cares what's in a .tsx file. Does that open up new opportunities to try something new, or, since it doesn't matter, does the industry as a whole just decide to use the most stable thing, forever?

In this time of great disruption, we get the opportunity to rethink best practices (or in Remix's case, re-rethink), and lay everything on the table again. That doesn't mean everything stays on the table, just that we'll take the good, leave the bad, and modify the ugly. The question of this article isn't one that needs refuting, it's one worth considering seriously.

As someone who has worked on open source frameworks in a full-time capacity for 3 years, I'm deeply interested in this question. I'm not interested in protecting myself/my craft, I'm interested in bettering my craft and having a good career. I am considering and also trying to predict (and make) the future. It's humbling to remember "I could be wrong", and it's encouraging to remember most everyone else will be.

In this article, I want to break the question and its implications down into their more fundamental elements, so I can rebuild a version of reality worth pursuing and building. To do that, it would be worth first considering what a web framework is. I find this really hard, since it's a very nebulous and general term, and you end up comparing Flask to jQuery to React to Next.js. Instead, I think it's more helpful to consider what value frameworks provide. I think this statement is sufficient:

Frameworks provide abstractions, structure, and constraints for building your website.

Imagine there's no React

It's easy if you try

No Svelte below us

Above us, only bi(nary)

Imagine all the people

Prompting for today

(Sorry, Svelte, for replacing you with the word "hell". It's not because I perceive a resemblance, I just liked the way it sounded.)

So let's return to the argument, and spell it out a bit more. This is the conventional wisdom I am hearing right now:

Since the models got good (circa Winter '25-'26) for agentic programming, I care less and less about the code (and you should too). This is particularly true with any frontend code, because it's all largely presentational. Therefore, if it looks good, it is good.

Given the state of the models, and given that React is already the most dominant UI framework, with the very popular meta-framework Next.js (plus a few other good choices like React Router and TanStack Start), there really is no need or value in trying anything else out. Plus, because there is vastly more React code out there in the wild, the models are trained more heavily on it and are therefore better (or at least more familiar) with React. The React singularity has already happened, accept it.

Obviously (I hope) I am now being a bit facetious. The argument is still worth considering, mostly because I see people cargo culting this opinion and React along with it into their vibe-coded apps. There are, however, some much more serious folks such as the Cursor team who do seem to be convinced that in the age of agentic programming using React is an advantage.

I'm tempted to dig into each of these claims:

I'm not actually sure of the value, though, particularly in arguing about React. I have a much bigger issue with the logic, and it stems from my original question: Do frameworks matter anymore?

Here's what I don't get about the argument: why React? Why any framework or UI library at all?

If LLMs have gotten so good at frontend code, and if people care less and less about the details of their HTML, JavaScript, and CSS and only care that it looks and behaves properly, then why even put a layer of abstraction between the LLM and the website? If ever there were a time to embrace Web Components, surely it's now.

React no longer has to be one's personality. Disclaimer: I say this as someone with a YouTube channel named "React Tips with Brooks Lybrand". Plus, we already have AI labs to make our new personality, so we'll be fine.

Since the models got good (circa Winter '25-'26) for agentic programming, it's easier than ever to build a beautiful and interactive website without having to worry about what we previously called DX (Developer Experience). My agent doesn't care about things like file-based routing, and why should I bother it with properly setting up a useEffect?

Plus, models are really well trained on JavaScript, HTML, and CSS (sort of), so there's really no need or value in adding any more layers of complexity.

I think there are some logical leaps and mistakes in this sentiment, but no more than in the first, more widely accepted one.

Ah, the web framework. Where does it start, where does it end? What's its purpose? Do we even need any at all? After all, what was so bad about jQuery? Has anyone made the argument yet that we should just let the agent use jQuery since it's well represented in its training data? If not, they should. An agent doesn't care about spaghetti code, right?

I'm old enough to remember the "framework wars" of the 2010s. When I did my own evaluation for my company at the time, I was picking between React, Angular, and Vue. Those were the "frameworks" we talked about. Gatsby existed, but wasn't general-purpose enough (static-site generation only). Next.js was pretty cool, but also pretty limited (no good mutation story). For the most part, if you were in the React ecosystem, you just used create-react-app (CRA) and maybe you ejected if you actually had someone on your team who thought SSR was valuable and wanted to set it up.

I ultimately picked React, and many other people did too. But why? What made React so compelling as a framework?

If you ask the React team why React won or why it's so great, they will likely say "composition". I find it very difficult to encapsulate exactly what made React so special, but I think this is a big part of it. I didn't really understand what "composition" meant early in my career and React usage. I just knew that:

I would learn later that React also provided server-side rendering (SSR) out the gate, making it look and feel a good bit like PHP with its HTML-in-your-scripting-language sort of experience. Setting this up was a bit more involved, especially for folks like myself who were more frontend-focused. This led to the rise of the "backend-for-frontend engineer" and the meta-frameworks like Next.js and Remix (the old one, sorry).

React was solving a number of problems. Despite what Mr. Rauch thinks (and ordinarily, he is pretty much on the money), React didn't "win" because it came with a component library that wraps a great style system and lower-level accessible components and utilities that you can own and morph to your own needs. shadcn/ui is awesome, don't get me wrong. But even within the component-library/design system story, it's the latest evolution in a long line of successors from Radix to Reach UI to Material UI to Bootstrap and many, many more that I'm skipping, forgetting, or unaware of. The existence of shadcn/ui on top of many other popular incumbents is a testament to what makes React great, not the other way around.

This long but brief diversion of why React "won" hardly does justice to the full history, and it certainly doesn't even touch on what makes other web frameworks interesting. Despite React's predominance, plenty of other frameworks and meta-frameworks get millions of weekly downloads and are loved by many a developer. It also completely glosses over the popularity of non-JavaScript-based frameworks such as Laravel and Ruby on Rails.

I don't know a better way to consider value frameworks provide without introspecting what made my first love, React, so special to me. React made it easier to build dynamic websites without ending up with spaghetti code, and spaghetti code was bad because it was costly to change and maintain in the long term. React enabled me, elevated me as an engineer, solved problems I didn't want to solve, and opened me up to an ecosystem of other developers who were making it better and building more useful tools on top of it.

As I stated at the top of this post, I think the value-add of a framework is pretty simple: frameworks provide abstractions, structure, and constraints for building your website.

This isn't even really a unique property of frameworks, this is true for all libraries, modules, classes, and functions. Code is a series of abstractions that express meaning and intent to computers and anything else that will manipulate or learn from that code. Previously, that meant humans, and we called it "reading the code", and so we cared a lot about things like variable names. These days the level of detail we care about is shifting and resettling. Maybe we're on some infinite curve and we'll care less and less about the trees until we don't even care about the forest. Personally, I'm doubtful, but I could definitely be wrong.

Either way, I think I still want a framework. I want code that's well tested, secure, easy to reason about, and that gets my agent in the grooves it needs to be in to produce results I like.

Alright, the jig is up, I'm being a little facetious when I ask "Do frameworks matter anymore?"

I recall that during a Q&A with the Core Team at React Conf 2024, Ricky Hanlon made this point:

You're either using a framework, or building a framework, and building a framework is really hard.

This wasn't the first time I'd heard this. In fact, at a prior job as an engineer on the web platform team of a Texas grocery store, we ran into the same thing. We built our own meta-framework around React to handle server-side rendering for initial requests, after which the application would hydrate the whole document and hand off routing on the client using React Router (v5?).

While we did have a cute name for this little meta-framework we made (exo, I believe, and no one could agree why it was called that), most engineers didn't think of it as a framework. I blame that mostly on the combination of a lack of features and a lack of marketing (why would we market an internal framework?). Nevertheless, we had still built our own framework, and it came with a lot of maintenance cost and burden, plus very few engineers actually understood how it worked, making it a pretty decent-sized liability.

Long story short, they started the process of moving off of this home-grown meta-framework and switching to Next.js. I didn't get to see the transition through because this was around the time I went to work with the Remix team at Shopify (of course we "joked" that it was this decision that drove me away).

The timeline of this anecdote is pretty definitively right before agentic programming would git gud. Assuming you're starting a greenfield project right now, and assuming it's not just for demonstration purposes or a 1-off presentational website, I think Ricky's statement is both more true now than ever, and a little bit wrong.

Let's start with the wrong: "building a framework is really hard". It's really not anymore. I mean, it depends on what you want. If you want a good, robust, bug-free, secure, full-stack framework, it's gonna take a lot more than a couple of prompts to really flesh out. And then when you start using it, you may find that LLMs can't really make it work for all the things you ask it to do, so they just quietly build hacks around your framework, and depending on how you're building this framework those hacks end up becomi