Solid 2.0 RC: The Big <Reveal>

GavinAnderegg 65 points 50 comments August 13, 2026
www.solidjs.com · View on Hacker News

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.

Semantic search powered by Rivestack pgvector
4,128 stories · 37,281 chunks indexed