I am a big fan of Signals. It’s the best state-management concept I've come across (also my team-mates). We even use it outside of the frontend space, e.g. in long running instances / services or complicated numpy calculations.
One of the core characteristics why it's so easy to reason about, is that the reactivity is indeed synchronous. We know most of the time, what every signal set() does when we constraint ourselves Effects not allowing to set other Signals.
Integrating async as first class citizen into the core is indeed interesting. I wonder how it impacts the ergonomics and state reasoning in the end.
This is excellent. Async being first class is definitely a paradigm shift compared to other frameworks. Vue has been trying to outdo Solid by the introduction of Vapour mode but now Solid has the upper hand once again.
(I see a lot of people complaining about AI use in writing the announcement. What they forget is, when you spend time actually writing and debugging code, these kind things that can be outsourced to LLMs should be. The important stuff is elsewhere and that's what matters. Not a blog post. Its purpose is to tell the users what to expect and the post does that well.)
> I see a lot of people complaining about AI use in writing the announcement. What they forget is, when you spend time actually writing and debugging code, these kind things that can be outsourced to LLMs should be.
the way you do something is the way you do everything. AI slop in one place of your work makes people think there's AI slop in other places too.
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.
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.
As much as the content and tech behind it is really cool, and I appreciate Ryan's ideas it does seem like a shame to culminate so much work with a very "sloppy" finish
Like a cold. Sometimes people call an illness a condition. A condition that can happen to you.
We have frameworks essentially living in a completely synchronous world--like a 2D plane--and they can't tell that there is another dimension out there except for when something inserts itself into its view out of nowhere. The protocol that we arrive at to deal with async is convoluted, because it is a state that is basically inflicted on the framework. That's what we sought to remedy.
Ah. The medical meaning, for an analogy. I think 99% of readers will, like me, take the software meaning. I'm sure Claude would know that if left to its own knowledge base, so I presume it was prompted to go way outside its training, hence the wierd word salad.
The article reads eerily like the Claude-authored drafts I did for some internal explanations of Relay’s design philosophy (it’s a GraphQL client I’ve been advocating for). I’m not one to make accusations of AI authorship, but it was a particularly striking impression with this one.
I had to rewrite the drafts very heavily in my own voice in order for people to enjoy reading them —- not that I’m a great writer, but I am human and people tend to appreciate that.
It was human written, fed to AI, human adjusted, re-fed, and around again — for days, with dozens of reviewers in between. (GPT 5.6 Sol doing the AI half of the lifting, for what it's worth.) So "nobody even looked at it" is the one criticism I can rule out. Everybody looked at it.
But you aren't wrong. The marketting heavy parts are where the tone shows. And honestly those are the parts I write worst. Exactly why I lean on AI there. When I ran before/after comparisons past reviewers, the polished versions kept winning. Maybe that's the norm creeping into how all of us write now. I notice it in my own sentences too. The words I choose. But given the choice between slightly synthetic and authentically clumsy, I tested both and shipped the one that read better.
Personally I don't think that a release announcement needs to be "marketing heavy" in the first place.
That's really the heart of the problem - in an effort to sound exciting, many parts of the article are just wasting the reader's time rather than simply explaining how things work clearly and directly.
No release announcement has the time to explain how things work. I actually think in hindsight what Rich did by including a video in the Runes announcement worked well. I will have a livestream tomorrow.
To be clear I’m not making any statement or implication about Ryan’s work or his quality as a developer. As someone who knows nothing about Solid I’m trying to read the article and understand what the USP is and struggling. And remarking on the AI tells in the writing.
Hey, I want to say that I love Solid as an alternative to react. I've been using it for hobby projects for 5+ years.
I'm at least one example of someone who prefers authentically clumsy. Users like me will be less likely to give Solid a chance if they cannot see that there are real humans with a vision behind it.
Because it's important. You don't want to read my raw writing. Try to read my HackMD and you see what you'd get. It's always taken me a lot of work to release my medium and dev.to articles. Grammarly working hard, and multiple human editors. It scales with how many people I think will read it. A release announcement is important. It needs to be clear and it needs to convey the most information in a very short span. You don't have the privledge to meander in this sort of thing. And meandering is exactly what I'd do if left on my own.
> The marketting heavy parts are where the tone shows. And honestly those are the parts I write worst. Exactly why I lean on AI there.
Everybody using AI to write slop do so because they think they can't write better but we all prefer a bad written article to the "correct" slop we are getting nowadays.
The AI tone in the announcement is light enough to be barely noticeable, but it’s there. Note that posting AI-generated comments to HN is explicitly forbidden.
Anyone who has spoken to me knows I talk in run-on sentences. I never complete a thought without interrupting myself. And I write the way I talk. I used to heavily edit that out of my writing, but now AI uses the proper punctuation and fills in where I miss words. It's like what I hear in my head but better. Because it is grammatically sound.
After:
Anyone who's spoken to me knows I talk in run-on sentences. I never complete a thought without interrupting myself. And I write the way I talk. I used to spend whole editing passes beating that out of my drafts. Now AI handles the punctuation and fills in the words I skip. It's what I hear in my head, but grammatically sound.
The result is almost always terser, more clear, and to the point. And usually all it takes is one more pass over to adjust anything I wouldn't say. In this case I kept the after verbatim just to illustrate my point.
I like my wording for `miss` better but I like the AI ending much better. This was just in a small two sentence response. I find over the course of an article the impact is much greater.
FWIW I also prefer the before. "whole editing passes beating that out" and "what I hear in my head, but grammatically sound" might not be immediate AI tells like 'and honestly' and 'load-bearing', but they are phrases you'd expect in a magazine article, not a forum comment. That kind of language in this context makes it smell like AI.
It's when you go top to bottom reworking parts of an article. Often later changes can impact earlier prose, so often I end up doing editing in several passes. That being said AI decided that term. It's actually more accurate to the actual process than what I originally wrote.
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.
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.
The challenge with this is we released too much at once. I really had a hard time with this announcement because I couldn't fit a full tour in less than a 6 article series. So how do I summarize?
I picked up on the async headlines and the infrastructure pieces. We talked a lot more about the new reactivity in the beta release. The plan from here as indicated in the article is a series of followups explaining parts of Solid 2.0 in more detail.
The key takeaways are:
1. We've solved declarative async, race conditions/complexity are reduced by the structure of your code.
2. We've collapsed the metaframework layer. Every Solid project out of the box is as capable as a metaframework based on the features you want to use. You can just start a simple client app and go from there.
The result is we are setting the stage that both Humans and AI can do things a single way and fall into the "Pit of Success" by the shape of the solution and the guarantees of the model.
I'm not sure you would, but I actually did this exercise a bit on stream after my last article. To try to show people what I was talking about. I actually ahve a really good example of this on some unreleased stuff that I can't talk about because its too future facing. After I write the final article I will share the other 2 versions.
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.
Yeah, like solid-universal (lets you target non-dom environments, state being derived and computed as little as possible, never again a glitch or disagreement because theres nothing to sync)
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.)
Yeah and I always found that really unfortunate. The truth is the JS Framework Benchmark hasn't really moved more that fractions of a percentage since we first hit the mark 7 years ago. Sure many frameworks have been on their way to catch up or have matched us since, especially in the last 2 years when they started adopting our architecture. But nothing is moving the dial. We might not be the fastest on there today but I view now as a line to hold, not as a place where any measurable gains can be made.
We can throw up a JS Framework Benchmark.. I obviously tested it a bunch locally, but mostly as a regression test. I also used Octane's new benchmark suite. Same sort of conclusions though. Everyone basically doing the same thing, some with compilers and some with more manual wiring (I haven't gone in and made PRs to update those to add that to Solid implementations in theirs), to the point this isn't a contention point. It was when everyone was as slow as React. But now everyone is more or less as fast as Solid.
Bundle size there is a regression though. Its natural cost of this feature. Async everywhere, means async doesn't tree shake. Hello World went from 4.7kb to 9.8kb simply because we can't tree shake it. I'm ok with that given what we deliver. Not everyone will be I'm sure. Svelte has also grown in size similarly over the same time. Basically leaving only minimalist solutions in that ~5kb range.. ie Preact + Signals etc..
But it also isn't really an announcement headline. So it is where we are at. I guess the takeaway. Still fast, still incredibly small considering what it does.
I've always appreciated Solid's DX/mental model (I _never_ have to think "when does this re-render?") so v2.0's continued wins on DX are remarkable. I never thought a release could be about how much can we _cut_. Primitives at work!
To be fair the writing has been on the wall for years for those paying attention. I never believed in Metaframeworks and it was this sort of awkward truth we had to deal with because the technology wasn't where it needed to be.
SolidStart 2.0 has a very important role of moving current projects into the future. Better tooling was key and it was that rewrite work that allowed me to hoist relevant parts into the core. Now every Solid project benefits from no FOUC in dev, preloading tag emission during SSR streaming etc...
I think this is inevitable collapse with AI. We want to look for our tools in a single place. It doesn't have to differentiate between React and Next when React is the one actually providing the features.
Aside, what sort of blog post content are you looking for?
I am a big fan of Signals. It’s the best state-management concept I've come across (also my team-mates). We even use it outside of the frontend space, e.g. in long running instances / services or complicated numpy calculations. One of the core characteristics why it's so easy to reason about, is that the reactivity is indeed synchronous. We know most of the time, what every signal set() does when we constraint ourselves Effects not allowing to set other Signals.
Integrating async as first class citizen into the core is indeed interesting. I wonder how it impacts the ergonomics and state reasoning in the end.
Need to test it out.
This is excellent. Async being first class is definitely a paradigm shift compared to other frameworks. Vue has been trying to outdo Solid by the introduction of Vapour mode but now Solid has the upper hand once again.
(I see a lot of people complaining about AI use in writing the announcement. What they forget is, when you spend time actually writing and debugging code, these kind things that can be outsourced to LLMs should be. The important stuff is elsewhere and that's what matters. Not a blog post. Its purpose is to tell the users what to expect and the post does that well.)
> I see a lot of people complaining about AI use in writing the announcement. What they forget is, when you spend time actually writing and debugging code, these kind things that can be outsourced to LLMs should be.
the way you do something is the way you do everything. AI slop in one place of your work makes people think there's AI slop in other places too.
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!
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.
As much as the content and tech behind it is really cool, and I appreciate Ryan's ideas it does seem like a shame to culminate so much work with a very "sloppy" finish
This might be more palatable: https://gist.github.com/aleclarson/da55bca36103d582a9720dd4a...
Is Claude really this bad, though?
E.g. "The problem that never went away was async. Every framework, including ours, treated it as a condition that happened to it."
Async treated as a condition?
And a condition happens?
And on grammar, the second it is ... the framework??
I rather suspect this is second-order output. Writings of a brain rotted by "AI".
Shame, because enough of the message gets through the fog to tell me the whole message would be worth receiving. I wish the project every success.
Like a cold. Sometimes people call an illness a condition. A condition that can happen to you.
We have frameworks essentially living in a completely synchronous world--like a 2D plane--and they can't tell that there is another dimension out there except for when something inserts itself into its view out of nowhere. The protocol that we arrive at to deal with async is convoluted, because it is a state that is basically inflicted on the framework. That's what we sought to remedy.
Ah. The medical meaning, for an analogy. I think 99% of readers will, like me, take the software meaning. I'm sure Claude would know that if left to its own knowledge base, so I presume it was prompted to go way outside its training, hence the wierd word salad.
The article reads eerily like the Claude-authored drafts I did for some internal explanations of Relay’s design philosophy (it’s a GraphQL client I’ve been advocating for). I’m not one to make accusations of AI authorship, but it was a particularly striking impression with this one.
I had to rewrite the drafts very heavily in my own voice in order for people to enjoy reading them —- not that I’m a great writer, but I am human and people tend to appreciate that.
Hey want to see what AI generates when I ask it to talk about Solid 2.0. It's not that. It is:
https://hackmd.io/@0u1u3zEAQAO0iYWVAStEvw/rJM9ws3Kbg https://hackmd.io/@0u1u3zEAQAO0iYWVAStEvw/H1Q8XTMSbe
It was human written, fed to AI, human adjusted, re-fed, and around again — for days, with dozens of reviewers in between. (GPT 5.6 Sol doing the AI half of the lifting, for what it's worth.) So "nobody even looked at it" is the one criticism I can rule out. Everybody looked at it.
But you aren't wrong. The marketting heavy parts are where the tone shows. And honestly those are the parts I write worst. Exactly why I lean on AI there. When I ran before/after comparisons past reviewers, the polished versions kept winning. Maybe that's the norm creeping into how all of us write now. I notice it in my own sentences too. The words I choose. But given the choice between slightly synthetic and authentically clumsy, I tested both and shipped the one that read better.
Personally I don't think that a release announcement needs to be "marketing heavy" in the first place.
That's really the heart of the problem - in an effort to sound exciting, many parts of the article are just wasting the reader's time rather than simply explaining how things work clearly and directly.
No release announcement has the time to explain how things work. I actually think in hindsight what Rich did by including a video in the Runes announcement worked well. I will have a livestream tomorrow.
Out of curiosity, did you use AI for this reply too? It reads a bit like it.
Ryan has given so much to this community... perhaps he gives too much.
To be clear I’m not making any statement or implication about Ryan’s work or his quality as a developer. As someone who knows nothing about Solid I’m trying to read the article and understand what the USP is and struggling. And remarking on the AI tells in the writing.
Is non-AI writing too much? I don't think his projects would have got as much attention if it was AI-written since the beginning.
AI knows how to spell “marketting”.
Hey, I want to say that I love Solid as an alternative to react. I've been using it for hobby projects for 5+ years.
I'm at least one example of someone who prefers authentically clumsy. Users like me will be less likely to give Solid a chance if they cannot see that there are real humans with a vision behind it.
Why do you need several human/ai iteration rounds and dozens of reviewers for a blog post?
Because it's important. You don't want to read my raw writing. Try to read my HackMD and you see what you'd get. It's always taken me a lot of work to release my medium and dev.to articles. Grammarly working hard, and multiple human editors. It scales with how many people I think will read it. A release announcement is important. It needs to be clear and it needs to convey the most information in a very short span. You don't have the privledge to meander in this sort of thing. And meandering is exactly what I'd do if left on my own.
> ... I tested both and shipped the one that read better
And there we have it. "AI"s prime use case. Best instead of good enough.
> The marketting heavy parts are where the tone shows. And honestly those are the parts I write worst. Exactly why I lean on AI there.
Everybody using AI to write slop do so because they think they can't write better but we all prefer a bad written article to the "correct" slop we are getting nowadays.
> And honestly
:)
The AI tone in the announcement is light enough to be barely noticeable, but it’s there. Note that posting AI-generated comments to HN is explicitly forbidden.
Before:
Anyone who has spoken to me knows I talk in run-on sentences. I never complete a thought without interrupting myself. And I write the way I talk. I used to heavily edit that out of my writing, but now AI uses the proper punctuation and fills in where I miss words. It's like what I hear in my head but better. Because it is grammatically sound.
After:
Anyone who's spoken to me knows I talk in run-on sentences. I never complete a thought without interrupting myself. And I write the way I talk. I used to spend whole editing passes beating that out of my drafts. Now AI handles the punctuation and fills in the words I skip. It's what I hear in my head, but grammatically sound.
The result is almost always terser, more clear, and to the point. And usually all it takes is one more pass over to adjust anything I wouldn't say. In this case I kept the after verbatim just to illustrate my point.
I prefer the former version. It sounds like a human.
I like my wording for `miss` better but I like the AI ending much better. This was just in a small two sentence response. I find over the course of an article the impact is much greater.
It is! But not in the direction you think!
FWIW I also prefer the before. "whole editing passes beating that out" and "what I hear in my head, but grammatically sound" might not be immediate AI tells like 'and honestly' and 'load-bearing', but they are phrases you'd expect in a magazine article, not a forum comment. That kind of language in this context makes it smell like AI.
I prefer the before.
> And I write the way I talk. I used to spend whole editing passes beating that out of my drafts.
What's an "editing pass"?
It's when you go top to bottom reworking parts of an article. Often later changes can impact earlier prose, so often I end up doing editing in several passes. That being said AI decided that term. It's actually more accurate to the actual process than what I originally wrote.
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.
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.
The challenge with this is we released too much at once. I really had a hard time with this announcement because I couldn't fit a full tour in less than a 6 article series. So how do I summarize?
I picked up on the async headlines and the infrastructure pieces. We talked a lot more about the new reactivity in the beta release. The plan from here as indicated in the article is a series of followups explaining parts of Solid 2.0 in more detail.
The key takeaways are: 1. We've solved declarative async, race conditions/complexity are reduced by the structure of your code.
2. We've collapsed the metaframework layer. Every Solid project out of the box is as capable as a metaframework based on the features you want to use. You can just start a simple client app and go from there.
The result is we are setting the stage that both Humans and AI can do things a single way and fall into the "Pit of Success" by the shape of the solution and the guarantees of the model.
For what it's worth, I would love to read the earlier drafts before the AI workshopped them.
I'm not sure you would, but I actually did this exercise a bit on stream after my last article. To try to show people what I was talking about. I actually ahve a really good example of this on some unreleased stuff that I can't talk about because its too future facing. After I write the final article I will share the other 2 versions.
If you made the framework you should be able to write the post explaining it, sorry
Why? Those are completely different skillsets
I did write the post. This is better.
I wrote an article on this. Maybe it helps? https://www.brenelz.com/posts/innovations-of-solid-2/
I love solid, but this article is very obviously AI-written. I too find it impenetrable.
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.
@solidjs/web is already neatly separated, so there is space for other targets.
Yeah, like solid-universal (lets you target non-dom environments, state being derived and computed as little as possible, never again a glitch or disagreement because theres nothing to sync)
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.)
Yeah and I always found that really unfortunate. The truth is the JS Framework Benchmark hasn't really moved more that fractions of a percentage since we first hit the mark 7 years ago. Sure many frameworks have been on their way to catch up or have matched us since, especially in the last 2 years when they started adopting our architecture. But nothing is moving the dial. We might not be the fastest on there today but I view now as a line to hold, not as a place where any measurable gains can be made.
We can throw up a JS Framework Benchmark.. I obviously tested it a bunch locally, but mostly as a regression test. I also used Octane's new benchmark suite. Same sort of conclusions though. Everyone basically doing the same thing, some with compilers and some with more manual wiring (I haven't gone in and made PRs to update those to add that to Solid implementations in theirs), to the point this isn't a contention point. It was when everyone was as slow as React. But now everyone is more or less as fast as Solid.
Bundle size there is a regression though. Its natural cost of this feature. Async everywhere, means async doesn't tree shake. Hello World went from 4.7kb to 9.8kb simply because we can't tree shake it. I'm ok with that given what we deliver. Not everyone will be I'm sure. Svelte has also grown in size similarly over the same time. Basically leaving only minimalist solutions in that ~5kb range.. ie Preact + Signals etc..
But it also isn't really an announcement headline. So it is where we are at. I guess the takeaway. Still fast, still incredibly small considering what it does.
A worthy and pragmatic tradeoff.
I've always appreciated Solid's DX/mental model (I _never_ have to think "when does this re-render?") so v2.0's continued wins on DX are remarkable. I never thought a release could be about how much can we _cut_. Primitives at work!
Solid 2 looks great! The async features are really interesting, I'll give them a try in my side projects. Congrats on the release!
Out of curiosity, I compared Solid 2 with Octane, the new JS renderer on the block.
https://gist.github.com/aleclarson/0f4266d63fd83c7a5ea551244...
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.
To be fair the writing has been on the wall for years for those paying attention. I never believed in Metaframeworks and it was this sort of awkward truth we had to deal with because the technology wasn't where it needed to be.
SolidStart 2.0 has a very important role of moving current projects into the future. Better tooling was key and it was that rewrite work that allowed me to hoist relevant parts into the core. Now every Solid project benefits from no FOUC in dev, preloading tag emission during SSR streaming etc...
I think this is inevitable collapse with AI. We want to look for our tools in a single place. It doesn't have to differentiate between React and Next when React is the one actually providing the features.
Aside, what sort of blog post content are you looking for?