Release v2.0.0 RC - The Big · solidjs/solid · GitHub

//releases/show" data-turbo-transient="true" />

· solidjs/solid">

· solidjs/solid" />

The hardest problems in UI frameworks were never about rendering. We've always had a DOM we could mutate efficiently. The early challenge was synchronization — showin..." /> · solidjs/solid" /><br>The hardest problems in UI frameworks were never about rendering. We've always had a DOM we could mutate efficiently. The early challenge was synchronization — showin..." />

Skip to content

Type / to search

Sign in<br>Sign upAppearance settings

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

Uh oh!

There was an error while loading. Please reload this page.

solidjs

solid

Public

Uh oh!

There was an error while loading. Please reload this page.

Notifications<br>You must be signed in to change notification settings

Fork<br>1.1k

Star<br>35.8k

v2.0.0 RC - The Big

Pre-release

Pre-release

Compare

Choose a tag to compare

Sorry, something went wrong.

Filter

Loading

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

No results found

View all tags

ryansolid

released this

13 Aug 17:53

&middot;

21 commits

to main<br>since this release

v2.0.0-rc.0

ff4d3c4

Solid 2.0 RC: The Big

The hardest problems in UI frameworks were never about rendering. We've always had a DOM we could mutate efficiently. The early challenge was synchronization — showing a consistent interface no matter what was going on, and doing it efficiently. Fine-grained reactivity solved that a decade ago. Update exactly what changed. Skip the rest.

The problem that never went away was async. Every framework, including ours, treated it as a condition that happened to it. Something a synchronous core would have to weather.

Today Solid 2.0 reaches Release Candidate, and it takes the other path: async is a property of the reactive system itself. It's part of the graph. That one decision runs through everything in this release. The model does more, so the framework does less.

Async Lives in the Graph

A computation can return a Promise(or Async Iterator), and everything downstream just understands. No special primitive to absorb it. No manual loading state. No null checks.

fetchUser(props.id));

return (<br>}><br>{user().name}

);<br>}">import { createMemo, isPending, Loading } from "solid-js";

function Profile(props) {<br>const user = createMemo(() => fetchUser(props.id));

return (<br>Loading fallback={Skeleton />}><br>h1 class={{ stale: isPending(user) }}>{user().name}h1><br>Loading><br>);

That's the whole data-fetching story. user is a memo that happens to be async. covers it until it's ready. When props.id changes, the old content stays visible while the new answer is in flight, and isPending tells you a change is coming — not "is anything fetching anywhere," but "is a new answer to this question on the way."

Derived state, error handling, transitions, optimistic updates all fall out of this one idea. And because async lives in the graph, the same components work whether their data comes from a client fetch, a server render, or a server function. The server story layers onto your app instead of replacing it.

The full async story deserves more than a section. A deep dive series starts next week.

Less to Learn, More to Use

Everything Solid 2.0 removes is something you had to learn. Everything it adds is something you get to use. These weren't features we cut. They were workarounds you had to learn. Now they're just how Solid works:

createResource — gone. Async flows through ordinary memos.

batch — gone. Everything batches. Writes apply on a microtask; flush() when you need them now.

startTransition / useTransition — gone. The graph holds a consistent state on its own; isPending and latest read it.

on and createComputed — gone. Split effects — createEffect(compute, apply) — separate tracking from side effects.

produce and createMutable — gone. Store setters hand you a draft you mutate. That's just how stores work now.

The 1.x migration guide maps every removal to its replacement.

The new APIs are a different story. You don't need optimistic stores, projections, actions, or reveal ordering to build your first app. You might not need them for your tenth. But when you do, they're there, and they work with everything else. Learn less, do more. And the runtime is only half of it.

One Plugin, Whole Platform

Our tooling made the same trade.

Solid 2.0 ships a new compiler toolchain written in Rust on top of OXC, and @solidjs/vite-plugin defaults to it automatically . Upgrade the plugin and you're compiling Solid with native tooling. Zero configuration. Nothing to migrate. The Babel preset remains available as an option.

Workload<br>babel-plugin-jsx<br>oxc...