SolidJS 2.0 Beta: A New Baseline for Async Reactivity
SolidJS 2.0 Beta marks a substantial evolution for the fine‑grained reactive framework, focusing on first‑class async handling and a more predictable reactivity model. After a long Experimental phase, the team skipped a traditional Alpha, with creator Ryan Carniato explaining that the remaining milestones no longer justified a separate stage. Instead, the beta lands as a cohesive package of reactive framework updates aimed at making asynchronous programming feel native rather than bolted on. Developers can now embrace SolidJS 2.0 async capabilities without complex workarounds, while still benefiting from the framework’s hallmark: high‑performance UI rendering without a virtual DOM. Community feedback so far highlights excitement around the streamlined async patterns and how they preserve Solid’s ergonomic feel. For teams already invested in Solid, the official migration guide and SolidStart‑specific instructions provide a clear path into this new generation of Promise handling in JavaScript-driven interfaces.
First-Class Async and Promise-Aware Computations
The centerpiece of SolidJS 2.0 async support is the ability for computations to return Promises directly. Where earlier versions required manual orchestration, developers can now pass a Promise straight into constructs like createMemo, and the reactive graph will suspend and resume automatically as data resolves. This elevated Promise handling in JavaScript means fewer custom wrappers, less glue code, and a more natural mental model: asynchronous values behave like any other reactive source. Pending state is expressed explicitly through helpers such as isPending(() => expr), avoiding the need to repeatedly tear down and rebuild UI trees. Combined, these changes simplify common patterns like data fetching, derived state from remote resources, and progressive enhancement, while keeping the fine‑grained reactivity that differentiates Solid from virtual DOM frameworks. As one community member noted, the async primitives now feel slick and cohesive, rather than an afterthought layered onto the core system.
Reworked Suspense and Stable Async User Interfaces
Suspense has been reimagined in SolidJS 2.0 to offer smoother async experiences. The new Loading behavior focuses specifically on initial readiness: it shows a fallback while a subtree is loading for the first time, then preserves the rendered UI on subsequent async updates. This design avoids the jarring effect some developers reported in the old Suspense model, where the UI could be “ripped away” when data changed. Instead of repeatedly remounting components, pending state is handled through explicit indicators like isPending, which decouples loading feedback from the lifecycle of the view itself. The result is more stable interfaces under asynchronous churn, especially in complex applications with nested data dependencies. For teams accustomed to patching Suspense-like behavior with custom logic, SolidJS 2.0’s reworked approach reduces boilerplate and clarifies when and where fallbacks should appear, aligning async UX more closely with user expectations.
Deterministic Batching, Mutations, and Derived State
Beyond Suspense batching, SolidJS 2.0 introduces deterministic microtask batching that changes how updates flow through the reactive graph. Writes to signals and stores are now queued, with reads only reflecting changes after an explicit flush() boundary. While some developers worry this may make reactive values feel less like normal variables, Carniato argues that this determinism is necessary for consistent async behavior. In practice, it offers clearer scheduling semantics and removes many subtle race conditions. New mutation primitives, including action() and createOptimisticStore, unify optimistic UI updates, server writes, and revalidation into a single declarative flow. Meanwhile, derived state is elevated via function forms like createSignal(fn) and createStore(fn), letting developers express computed data as first‑class primitives rather than ad‑hoc effects. Together, these changes shift more complexity into the framework itself, so application code can focus on intent: what should happen, not when it will run.