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.
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.
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.
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.
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.)
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.
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 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.
Congrats on the release! Nice to see transitions API go away, though I am not entirely convinced of the async model. It's capability is impressive, yet I do not like hiding what values are async, and throwing to await like React has never seemed a good solution.
As I see it, this is a whole new level of DX. One simple unified API for all fetching and reactivity problems. I'm not sure if I'm overestimating this or others underestimating or not understanding how significantly this simplifies data and state management. Congrats to Ryan and the team.
15 comments
[ 0.22 ms ] story [ 11.7 ms ] threadObviously 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.
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!
I just hoped that announcement would be another blog post.
https://gist.github.com/aleclarson/0f4266d63fd83c7a5ea551244...
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.
(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.)
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.
urgh