SolidJS 2.0 Makes Async a First-Class Feature for Reactive Apps

SolidJS 2.0 Beta: A Rethink of Async and Reactivity

The SolidJS 2.0 release enters beta with a focus on making asynchronous behavior a core part of its reactive framework updates. Rather than shipping an alpha, the team iterated for an extended period in the Experimental channel, which led creator Ryan Carniato to conclude that a separate alpha phase was unnecessary. The result is a sweeping redesign of async handling, the reactivity model, and overall developer experience, all while maintaining Solid’s hallmark fine-grained reactivity without a virtual DOM. For developers used to juggling manual orchestration around Promises, effects, and loading boundaries, this release aims to move much of that complexity into the framework itself. SolidJS 2.0 is available as a beta on npm under the “next” tag and is accompanied by migration guides for both core Solid and SolidStart, signaling that the ecosystem is being brought along for the transition.

Async as a First-Class Feature in the Reactive Graph

The headline feature of the SolidJS 2.0 release is that async is now a first-class feature woven into the reactive graph. Computations can directly return Promises, and Solid will automatically handle suspension and resumption, allowing developers to pass a Promise into utilities like createMemo without extra plumbing. Pending states no longer require tearing down and rebuilding UI trees; instead, developers can express them declaratively with isPending(() => expr). This approach simplifies asynchronous data flows by aligning them closely with synchronous reactive patterns, reducing the mental gap between the two. Community feedback so far has been enthusiastic, with developers describing “relief and joy” at seeing async treated as a first-class citizen and praising how “slick” the proposed patterns look. For teams that frequently coordinate server calls, user input, and derived state, SolidJS 2.0 promises a more cohesive and ergonomic async story.

Reworked Suspense and Loading for Smoother UX

Suspense improvements are central to how SolidJS 2.0 handles asynchronous rendering and loading states. The Loading behavior has been redesigned to focus strictly on initial readiness, showing a fallback while a subtree loads for the first time but keeping the UI stable during subsequent updates. Instead of the previous pattern where Suspense could “rip the UI away” during later async transitions, the new model emphasizes continuity: the interface stays visible while pending state is reflected elsewhere, such as through isPending. Early adopters have noted that the previous Suspense behavior could feel jarring; the 2.0 approach aims to make async transitions feel more natural and less disruptive. In practice, this means users are less likely to see whole sections of the UI disappear and reappear as data changes, aligning Solid’s Suspense behavior more closely with expectations for modern, responsive web applications.

Deterministic Batching and New Primitives for Mutations

Under the hood, SolidJS 2.0 introduces deterministic batching to make reactive updates more predictable. Updates are microtask-batched, and reads only reflect changes after an explicit flush() step, making the scheduling model more consistent in the presence of async operations. While some community members expressed concern that “value updates after flush” depart from the intuitive behavior of immediate signal reads, Carniato argues that this model is necessary for consistent async semantics and ultimately leads to clearer boundaries. New mutation primitives support this model: action() and createOptimisticStore allow optimistic UI updates, server writes, and data revalidation to be expressed as a single flow. Derived state is elevated through function forms like createSignal(fn) and createStore(fn), making it easier to express computed state without leaning heavily on effects. Together, these changes aim to reduce reactive edge cases while improving performance.

Breaking Changes and the Evolving Developer Experience

The SolidJS 2.0 release also brings notable breaking changes that reshape how developers structure components. The Index control flow is replaced by , and For children now receive accessors, aligning control structures more closely with the underlying reactivity. createEffect is split into separate compute and apply phases, and onMount is replaced by onSettled, all in service of clearer async boundaries. Store setters now follow draft-first semantics by default, and the use: directive system has been removed in favor of ref directive factories. Some developers worry that the new split-phase createEffect feels more cumbersome and makes nested reactive logic harder to express. In response, Carniato emphasizes that these choices are the result of extensive exploration and that, used properly, they should reduce the need for createEffect altogether. Migration guides aim to help teams adapt without losing productivity.