Async as a First-Class Citizen in SolidJS 2.0 Beta
SolidJS 2.0 beta marks a decisive shift in async handling JavaScript by elevating asynchronous computations to first-class status. Developers can now return Promises directly from computations, with the reactive graph automatically handling suspension and resumption. This means primitives like createMemo can accept a Promise without extra wiring, significantly reducing the manual orchestration previously needed to coordinate async data and UI updates. The change responds to long-standing community desires for more ergonomic async patterns, with early adopters describing the new primitives as both “slick” and thoughtfully designed. By deeply integrating async into the core reactivity model rather than layering it on top, SolidJS positions itself as a reactive framework update that addresses the complexity of modern, data-heavy interfaces while preserving its hallmark fine-grained reactivity and performance advantages over virtual DOM-based solutions.
Reworked Suspense and Loading: Smoother Async UX
The SolidJS 2.0 beta introduces a reimagined Suspense system aimed at making asynchronous UI states feel less jarring. The new Loading behavior focuses strictly on initial readiness: it shows a fallback while a subtree loads for the first time, then keeps the UI stable during subsequent updates. Instead of tearing down and rebuilding the interface whenever data changes, pending state is now surfaced via isPending(() => expr), allowing developers to express loading intent without disrupting the view. Early feedback highlights how the previous Suspense behavior could feel like it “ripped the UI away,” whereas the new model emphasizes continuity and predictability. Together with first-class async, these Suspense improvements help unify data fetching, transitions, and user feedback within a single, coherent mental model, making Solid’s approach to async handling JavaScript feel more natural for everyday frontend workflows.
Deterministic Batching and a New Reactive Core
Under the hood, SolidJS 2.0 beta reshapes its reactive engine around deterministic batching and clearer state boundaries. Updates are now batched at the microtask level, with reads becoming visible only after an explicit flush() step. This makes the scheduling model deterministic and better aligned with consistent async behavior, but it also changes long-standing expectations that signal writes immediately affect subsequent reads. Some developers worry this introduces inconsistent-feeling state reads, yet Solid’s creator argues the model is necessary to achieve truly coherent async semantics. At the same time, derived state is elevated through function-based forms like createSignal(fn) and createStore(fn), turning derived computations into first-class primitives. Combined with the action() helper and createOptimisticStore for optimistic updates and server writes, the new model aims to absorb complexity into the framework so application code can remain simpler, even as reactivity becomes more powerful and predictable.
Breaking Changes, Migration, and the Future of Reactive Frameworks
Beyond async and batching, the SolidJS 2.0 beta ships with a series of breaking changes that signal a broader architectural evolution. Index is replaced by

