Solid 2.0 RC: Async Becomes a First-Class Citizen of the Reactive Graph
Solid 2.0 RC: The Big <Reveal>
Solid 2.0 Release Candidate rethinks async handling by integrating it directly into the reactive graph, eliminating the need for createResource, batch, and transitions. The new compiler, built on Oxc, delivers up to 355x speedups, and the Vite plugin's start mode replaces SolidStart, offering SPA, SSR, and server functions out of the box. With a migration guide and assistant, the ecosystem is ready for this major update.
The problem that never went away was async. Every framework, including ours, treated it as a condition that happened _to_ it. Something a synchronous core would have to weather. Today Solid 2.0 reaches Release Candidate, and it takes the other path: async is a property of the reactive system itself.
- MisterKent
Hey Ryan, just want to congratulate you on this. I've _loved_ solid since well before it's v1 release, and use it in all my side projects.
If anyone hasn't tried it I highly recommend it. Simply put: Solid makes the "dumb and naive code" the optimal code. It takes all the pain of React away.
I agree with your sentiment that we've pushed web frontend performance as far as we should bother. I think optimizing calls is the next frontier. On that end, I like the approach for async, but maybe I have a suggestion?
Solid needs a tightly coupled request library that emits signals/resources directly. That "server-side" data binding layer would be the missing glue. I think server actions sort of get at that, but I've never really been satisfied with them. Just my 2c.
Step one of all my projects is always wrap a bunch of fetch calls into whichever correct incantation of solid primitives. Plus, the solid compiler should be able to early load those requests via static analysis and improve real life FCP / LCP times without the developer needing to do gymnastics.
- ruby14
To me this feels like true innovation in the space compared to other popular frameworks’ handling of async. In other frameworks it feels bolted on and with several gotchas; here it feels that it’s actually part of the framework. The new primitives are intuitive and they compose well, resulting in async-aware UI code that is more declarative. You get so many behaviors that you would have to manually account for in other frameworks for free.
What’s also interesting to me is that it seems like it’s colorless. Your async state is used just like any other synchronous signal state.
Really excited to start playing with it!
- genshii
Maybe I just need to get over it, but this post reeks of Claude-isms and it immediately makes me stop caring about what the post has to say.
Obviously having an LLM write these kinds of things is the norm now, but what doesn't have to be the norm is the writing style. The way Claude (and other popular LLMs) write is so obnoxious and verbose. I think a simple pass of "make this more terse and to the point" would do wonders here.
- terabytest
As much as I’m trying to understand what’s groundbreaking here, and I’m really trying to appreciate it, the prose style of the article makes it completely impenetrable. I’m trying to understand what makes Solid 2.0 special, but I’m coming up completely empty, because it feels like I’m just reading noise.
- unlog
I keep wondering if the next step of Ryan should be to raise this a step further and bring it to anything-ui, not just the web. It's obviously a step forward, but that step could be mean a lot more than it really seems to be.