Innovations of Solid 2.0

Posted on:August 13, 2026

Introduction

So Solid 2.0 release candidate is now out and I’ve been trying to think of how to best market it. It’s not just a “faster React”, it’s something different. Something pushing the boundaries of what’s possible with frontend UIs.

Today I want to show you why it’s worth paying attention to by showcasing its innovations.

Async is derived and part of the graph

Async is the main headlining feature of Solid 2.0. It is the source of a lot of app complexity and in 2.0 Solid takes this head on for you. Work on Solid 2.0 began a long time ago, and Ryan has been thinking about this problem even longer.

The first inkling of modeling async as derived was the gaining popularity of Tanstack Query. This eventually led to the async solutions we have now. Async used to be seen as something outside of the system. E.g. fetching in a useEffect.

In Solid 2.0, async is just part of the reactive graph. You can hand a promise to a derived value and read it like anything else:

const user = createMemo(() => fetchUser(props.id));

// read it like a normal signal; the boundary handles the rest
return <h1>{user().name}</h1>;

So why should you care?

  1. Performance - blocking higher than needed with async is the biggest cause of slow loading times. When async lives in the graph, the framework can see your data flow — which opens the door to things like detecting waterfalls for you.
  2. DX - Figuring out how to structure your async is the source of a lot of bugs in applications these days. if(loading) guards can be a thing of the past.

Coordinated async as the default

This builds off the previous concept. With async being a part of the graph it makes sense that we can coordinate it. Have you ever pressed a button multiple times just to have the UI flicker through intermediate states that are useless? This is what uncoordinated async looks like. The network requests all come in at separate times and make for a janky experience.

Solid takes inspiration from both React and Svelte here. Svelte asked why can’t we coordinate all async without an explicit transition api. Solid took this and applied React’s stronger guarantees on top of it.

With this coordination in place Solid can also hold values in the past, and prevent the yank back to Suspense fallback.

Now making all async coordinated usually makes for poor performance — you’re potentially keeping two versions of the world alive at once. Solid innovated here with their disposal system to not take a big hit.

So why should you care this time?

  1. UX - Adds the ability to make less janky UIs.
  2. DX - It’s just easier to implement UIs in a correct way.

Stores are a superpower

Stores are unique to Solid. Svelte has collapsed them into one $state rune, and React just has useState. This split is intentional in Solid and it’s not something I understood for a very long time. They are a way to represent objects or arrays as a collection of signals. You update one leaf of the state, and the rest of the state stays quiet.

const [todos, setTodos] = createStore([...]);

// only the checkbox for todo 3 updates — nothing else re-runs
setTodos(todos => {
    todos[3].done = true
});

They are also seen as mutable reactivity, the counterpart to immutable reactivity found in most other frameworks. This is why the Solid store setter uses a produce style draft that you mutate. This allows you to keep identity of rows, even when you refresh from the server and reconcile the data — your list doesn’t get torn down and rebuilt just because the server sent fresh JSON.

Benefits this time are mostly performance based, and they compound with everything else in this post. Stores are what make the optimistic state story below so clean.

Optimistic state that makes sense

Optimistic state is something I’ve generally found pretty cumbersome. For this reason, I haven’t actually used useOptimistic in React too much. Solid’s optimistic state just makes sense.

Optimistic state is treated as a temporary overlay on top of the source of truth. It lasts only for the lifetime of a transition. Not having to worry about doing the revert yourself is great.

When things hold by default like they do in Solid, you usually either want to show a loading indicator or pretend the future is already here. With Solid you can do both with isPending and createOptimistic.

Combine optimistic state with stores and the whole pattern collapses down to almost nothing:

const [optimisticTodos, setOptimistic] = createOptimisticStore(todos);

const addTodo = action(async newTodo => {
  setOptimistic(todos => todos.push(newTodo)); // instant UI
  await saveTodo(newTodo); // server catches up
  refresh(todos);
});

Optimistic state is pretty crucial for some applications so definitely a UX win. Just look at the popular Trello demos that were being built a while ago. Making the UX win as easy to accomplish as possible is surely also a DX win. The Trello demos have basically been reduced to one createOptimisticStore primitive.

Core signals built on R3

R3 is a pretty amazing project from Milo on the Solid core team. He took inspiration from Alien Signals and his previous work. This is the engine behind the Solid core that is innovative in its own right.

I’m not an expert on it, but just know that a lot of thought went into this design. Signals have generally been a push-pull-push system, but this new setup is primarily push with a fallback to the old push-pull-push system. From my understanding it’s based on height ordering of the deps.

This is both the foundation of Solid 2’s performance as well as the underpinnings of the new projections primitive.

Built in metaframework tools

Metaframeworks have lately been seen as a requirement. Solid 2.0 challenges that fact by giving you the primitives to build your own framework as you see fit. Need server functions? Just enable a boolean. Solid’s lower level approach benefits it here by leaving the more opinionated pieces to you the author to stitch together using your AI agent. It has taken great steps to avoid some of the fracturing that you see in the React ecosystem. Should I choose React or Next is no longer a question.

Server components that solve the double data problem

Ryan has questioned whether RSCs actually solved the problem they set out to. Spoiler alert is he might have figured it out. Stay tuned.

Conclusion

So what do you think? Do any of these innovations interest you enough to try Solid or are you happy with the status quo?