Frameworks don't matter anymore...

Every year, Ryan Carniato, the creator of Solid JS, and more importantly,

the man responsible for pushing the entire ecosystem to the lightweight

signal-based reactivity model, posts a really interesting overview of the

state of JavaScript and his take on the major web dev trends moving forward.

While the AI news is gaining all the attention these days, there is still a lot going on in

the JS world, so in this Monday Morning Review, we’ll dive deep into the architectural shifts

that are actually changing how we build modern apps for the web. More importantly,

it looks like we are finally over the framework wars decade, and we are entering a new web dev era

where your choice of a framework doesn’t really make much of a difference anymore. Let me explain.

The React problem is probably one of the biggest highlights in 2025. It’s no secret that React,

despite its massive popularity, has a huge problem in the context of modern web frameworks.

What started as a simple UI library is now an ecosystem that requires a

full mental re-education just to render a button without accidental re-renders,

hydration bugs, or suspense waterfalls.

Their strong dependency to the virtual Virtual DOM

is considered architectural overhead and a liability by today's standards.

On top of that, React Server Components is mostly viewed as a flawed architecture

by the community because it blurs the line between server and client

in a way that creates a 'mental tax' few developers are willing to pay.

Furthermore, the React compiler, which was introduced to abstract away some of the complexity

developers face with manual memoization, is now seen by many as a double-edged sword.

While it promised to automate useMemo and useCallback,

in practice, it has become another layer of "magic" that makes debugging even harder.

In his "Heading into 2026" review, Ryan Carniato notes that instead of simplifying the mental

model, the compiler often acts as a band-aid for React's underlying architectural debt.

Because React's unit of reactivity is the entire component function, the compiler

has to perform heroic feats of static analysis just to prevent basic performance regressions.

And what’s worse is that the React popularity cycle,

which was once its greatest strength, can actually become a liability in the AI slop era.

We have entered a phase where LLMs are the primary way many developers interface with code. Because

React has the largest training set in history, AI is incredibly good at generating React code.

But here’s the catch… React went through many iterations, and its lack of imposed structure

led to a lot of questionable architectural decisions. And AIs were trained on all this mess,

which naturally leads to the "regression loop" we all heard so much about these days.

Because React has the largest training set in history,

LLMs are biased toward the "average" React code written over the last decade.

If you ask an AI to build a component in 2026, depending on your luck at the slot machines,

you could get a bunch of deprecated dependencies, some useEffect hooks,

and a state management "anti-patterns" that were considered best practice in

2019. If you are really lucky, you could even get a class-based component instead of a function one.

Ryan argues that the industry's obsession with React's "AI-friendliness" is actually

holding us back. There is a growing sentiment that "React is the Last

Framework" simply because the AI is so good at writing it.

But if we stop innovating because the AI can "handle" the complexity of the Virtual DOM,

we are effectively building the future of the web on top of a frozen mental model

that no longer matches how browsers, networks, or users actually behave.

One concrete example Ryan points to is the Remix 3 rewrite,

which is interesting precisely because it cuts against the usual “AI-first” instincts.

Instead of adding more framework-specific abstractions to help AI reason about intent,

Remix is actively removing them. This is a fancy way of saying that they are

basically going back to vanilla JS and reinventing the wheel for the tenth time.

Granted, I might sound cynical here,

but this actually represents a broader shift in web development sentiment.

When modern frameworks advertise progress by deleting abstractions instead of adding them,

it’s a signal that the abstraction ceiling has already been hit.

This naturally leads into what Ryan describes as the isomorphic-first framework phase.

After years of pushing more logic to the server under the banner of performance,

many teams quietly realized that server-driven UI

models break down when confronted with the expectation of modern web interactivity.

Islands and React Server Components make sense if your main goal is to achieve a

perfect score in Lighthouse, but they start to crack under the weight of real interaction,

long-lived client state and complex user flows.

The main issue is that Islands and RSCs are regressions toward

classic multi-page applications with the familiarity of JavaScript dev experience.

Navigation becomes declarative again, mutations become page-oriented and

client logic is fragmented by serialization boundaries. So now, every “simple” interaction

has to cross an invisible server/client fault line, and that mental overhead compounds fast.

So, after they changed course from SPAs to the server,

the frameworks are now quietly reversing course.

In Ryan’s words, “we’ve seen both Tanstack Start and SvelteKit join

SolidStart in bringing patterns like Out-of-Order streaming, Server Functions,

granular Optimistic UI, and Single-Flight mutations to their respective ecosystems.”

I can imagine that if you are not spending your free time reading all the release notes

from these JS frameworks, some of these concepts might sound abstract or unnecessarily academic,

so let’s quickly see what they are actually about.

Out-of-order streaming means the framework does not have to wait for all data to arrive before

showing anything. Parts of the UI render as soon as their data is ready, and the page keeps

updating as more data comes in. As a result, users are not blocked by artificial loading states.

Server Functions are a bit more nuanced because we are tightly coupling server logic and client

code on purpose. Sure, there are advantages to doing this. Errors behave like normal errors,

there are no hidden serialization rules and no fake “components” running on the server. However,

call me a grumpy old man, but I remember when this was called RPC,

and why we all jumped ship to REST in the first place.

The concept of Granular Optimistic UI is more interesting, and it comes from moving away from

component-level reactivity. When a small piece of state changes, only that value updates. The

rest of the UI stays untouched. The UI updates immediately, then syncs with the server later.

This works reliably when reactivity is based on individual values instead of whole components.

Finally, single-flight mutations deal with duplicate actions. Users click multiple times,

networks retry, and multiple tabs send the same request.

Instead of handling this manually, frameworks now deduplicate these mutations automatically.

One action triggers one mutation, and all consumers receive the same result.

Note that none of these concepts are novel, but web devs are usually the last to arrive

at conclusions everyone else has already reached, and then spend another decade arguing about them.

And this brings us to the isomorphic-first mindset. For the last decade, we’ve treated

the server and the client like two different countries with a very expensive border crossing.

The backend had its own set of rules and best practices,

while the frontend had different tooling and mental models.

But Ryan argues that the frameworks winning right now,

are erasing that border entirely. They aren't "Frontend Frameworks" anymore,

they are "Application Frameworks" where the code doesn't care where it lives.

And here is your Awesome trivia for the day. The concept of isomorphic JavaScript is not

new. One of the first frameworks that seriously pushed this model was Meteor,

back in 2012. The pitch was simple and radical at the time: write your logic once, run it on both

the server and the client, and stop pretending they are fundamentally different worlds.

It made a lot of buzz back then, and it was actually one of the first real JS frameworks I

built something useful into. However, even though the framework still has a following on GitHub,

the chances are this is the first time you are hearing about it. Meteor failed for a

lot of reasons, ranging from tight coupling to global state problems and scaling nightmares.

Ryan might be able to make this model work and bring it back to life like

it did with the Knockout JS signals reactivity.

However, I have to be honest, and after 15 years of web dev, I’m kind of checked out when

it comes to yet another year of big changes in the ecosystem. And probably I’m not the

only one. At this point, I feel like I have gone through enough large-scale projects to

know that the tools we have right now are good enough. And, if you actually hit a limitation,

you can always go back to good old Vanilla JS, which apparently is making a comeback in 2026.

If you liked this video, you should check out one of these ones next.

Please smash the buttons hard, and, until next time, thank you for watching!