Async as a First-Class Feature in SolidJS 2.0
SolidJS 2.0 Beta marks a decisive shift: async is now built into the core reactive model rather than layered on top. Computations can directly return Promises, and the reactive graph understands how to suspend and resume them automatically. In practice, this means developers can pass a Promise straight into helpers such as createMemo and let the framework orchestrate loading, resolution, and propagation through the UI. Manual wiring of async state—tracking separate loading flags, error signals, and result values—is reduced, replaced by a more declarative flow that matches how async JavaScript is written elsewhere. Early community reactions highlight genuine relief at this simplification, describing the new async primitives as both slick and thoughtfully designed. For teams evaluating async JavaScript frameworks, this iteration pushes SolidJS further into the conversation for applications where async behavior is dominant, not incidental.
A Reworked Suspense and Loading Story
SolidJS 2.0 also revisits Suspense implementation and loading patterns, addressing long‑standing complaints about jarring UI transitions. The new Loading primitive focuses strictly on initial readiness: it shows a fallback while a subtree loads for the first time, then avoids tearing down the UI on subsequent async updates. Instead of repeatedly swapping in and out entire sections, the system keeps the UI stable and relies on a dedicated isPending(() => expr) helper to express pending state. This separation between initial load and ongoing async work leads to more predictable reactive programming patterns, especially in data‑heavy views. Developers migrating from the previous Suspense behavior describe the earlier experience as having the UI suddenly “ripped away,” and report that the revamped model feels calmer and easier to reason about. Combined with first‑class Promise support, async data fetching starts to feel less like an add‑on and more like a native capability.
Deterministic Batching and a New Reactive Core
Under the hood, SolidJS 2.0 introduces deterministic batching to tighten its already fine‑grained reactivity. Updates are microtask‑batched, and reads see the new values only after an explicit flush() boundary. This makes the scheduling model more predictable in async scenarios, where interleaving writes and reads can otherwise result in subtle timing bugs. The change is not without controversy: some developers worry about reactive values no longer updating immediately like normal variables, and about the impact of splitting createEffect into separate compute and apply phases. SolidJS creator Ryan Carniato argues that both decisions are necessary trade‑offs to achieve truly consistent async behavior and clearer boundaries. Alongside this, derived state gets first‑class treatment via function forms such as createSignal(fn) and createStore(fn), while action() and createOptimisticStore unify optimistic updates, server writes, and revalidation in a cohesive flow.
Positioning SolidJS Against React and Vue for Async-Heavy Apps
With SolidJS 2.0, the framework leans hard into its identity as a fine‑grained, no‑virtual‑DOM alternative to React and Vue. By making Promises, Suspense‑style loading, and deterministic batching core concepts rather than peripheral utilities, it directly targets pain points that emerge in async‑heavy applications. React developers will recognize ideas like Suspense, but Solid’s implementation is tightly coupled to its signal‑based reactivity, avoiding reconciliation overhead and offering more granular control. Compared to other async JavaScript frameworks, Solid’s goal is to absorb complexity into the library so application code stays declarative and minimal, ideally reducing the need for lower‑level primitives like createEffect in everyday code. Migration guides for SolidJS and SolidStart aim to smooth the transition from 1.x, suggesting that the team expects production adopters to treat this beta as a serious candidate for upcoming projects where async behavior is central.
