Solid 2.0 RC: The Big <Reveal>
GavinAnderegg
65 points
50 comments
August 13, 2026
Related Discussions
Found 5 related stories in 86.5ms across 4,128 title embeddings via pgvector HNSW
- CodePen 2.0 robin_reala · 154 pts · July 30, 2026 · 46% similar
- Show HN: A Rosetta Stone for UI component libraries ch-bas · 13 pts · August 13, 2026 · 45% similar
- The SvelteKit 3 Release Candidate is here pier25 · 13 pts · August 13, 2026 · 44% similar
- Show HN: I built a zero-latency developer tool suite in pure Vanilla JavaScript AAPD_Studio · 19 pts · July 23, 2026 · 44% similar
- A Preview of DuckDB v2.0 ibotty · 588 pts · August 17, 2026 · 44% similar
Discussion Highlights (9 comments)
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.
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.
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!
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.
agila90
SolidStart 2.0 was just announced a week ago and immediately placed into maintenance mode. That's an interesting move. I just hoped that announcement would be another blog post.
AlexErrant
I'm a little surprised that there's no mention of end-user perf and that it's not on the js-framework-benchmark. Not an accusation; just noticing the lack of emphasis (perhaps natural, given how much Solid 1.0 was famous for its speed/minimal bundle size to the point of taking over the whole conversation.)
damsta
Solid 2 looks great! The async features are really interesting, I'll give them a try in my side projects. Congrats on the release!
retropragma
Out of curiosity, I compared Solid 2 with Octane, the new JS renderer on the block. https://gist.github.com/aleclarson/0f4266d63fd83c7a5ea551244...
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.