Async Becomes a First-Class Feature in SolidJS 2.0 Beta
SolidJS 2.0 beta marks a major shift in how the framework treats asynchronous code. Async is now a first-class feature, meaning computations are allowed to return Promises and the reactive graph takes care of suspending and resuming for you. In practice, this lets developers pass a Promise directly into helpers such as createMemo while SolidJS coordinates loading, resolution, and UI updates behind the scenes. The change significantly reduces boilerplate that previously surrounded fetching data, orchestrating side effects, or keeping derived values in sync with async operations. Community feedback so far has been enthusiastic, with developers describing a sense of “relief and joy” at the new async model and praising how clean the patterns look. For teams building data-intensive interfaces, these JavaScript framework updates directly target the pain points of wiring Promises into a fine-grained reactive system.
Reworked Suspense and Loading for Smoother Async UX
Alongside async as a first-class feature, SolidJS 2.0 beta ships a reworked Suspense-like experience focused on more stable interfaces during async transitions. The new Loading behavior is scoped to initial readiness: it shows a fallback only while a subtree is being loaded for the first time. Once the data is ready, the UI stays put during subsequent updates instead of being torn down and rebuilt. Pending state now flows through an explicit isPending(() => expr) primitive, allowing developers to render loading indicators without letting the framework rip existing UI away. Early adopters noted that the previous Suspense behavior could feel jarring when it replaced whole sections of the page during refreshes. The updated design aims to make async UX feel calmer and more predictable, particularly in applications that frequently revalidate or refetch data.
Deterministic Batching and a Refined Reactivity Model
SolidJS 2.0 also reshapes its core reactivity model to better align with complex async flows. Updates are now microtask-batched, and reads reflect changes only after an explicit flush() step, giving the framework a deterministic scheduling model. This makes how and when updates appear more predictable, especially when async operations interleave with UI reads. Ryan Carniato, SolidJS’s creator, acknowledges that this shift and the split-phase createEffect API may feel harder to accept at first, particularly for developers used to immediate signal reads and automatic dependency tracking. Some community members worry about inconsistent state reads and more cumbersome patterns. Carniato argues that these choices are necessary for truly consistent async and that, once patterns settle, developers will rely less on createEffect overall. The intent is for SolidJS to absorb the complexity so application code can stay simpler and more declarative.
New Primitives, Less Boilerplate for Async Workflows
Beyond core reactivity, SolidJS 2.0 beta introduces new primitives that condense common async workflows. The action() helper, combined with createOptimisticStore, lets developers express optimistic updates, server writes, and data revalidation as one coherent flow rather than scattered callbacks and manual state juggling. Derived state is also elevated to a first-class concept with function forms like createSignal(fn) and createStore(fn), which generate state from other sources without extra glue code. These changes reduce boilerplate around wiring together async requests, UI updates, and cache reconciliation. The release does include breaking changes—Index is replaced by
