ryansolid
ryansolid on Hacker News
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.
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.
I did write the post. This is better.
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.
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.
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.
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.
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 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.
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?
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.
Yeah it is an interesting one. There is definitely a slowdown due to the amount of wrapping that happens. These sort of libraries tend to put component in component in component etc.. so there is a lot of prop iteration, Object.keys calls in Object.keys calls etc which when used with proxies can add up a bit.
The tricky part is no one actually knows how slow these libraries are in say React. My suspicion they are slow there as well but maybe not as stark of a difference because of how fast Solid to begin with comparatively.
People who use Solid tend to measure stuff like this where as those who use React might have already reconciled themselves to performance issues.
Thank you for correcting this. I was going to come and respond when I saw this earlier but hadn't had a chance. Yes the annoying part is not being able to destructure but you definitely don't have to (and it isn't our recommendation) to pass accessor functions down as props. I wrote an article on our perspective here:
https://dev.to/this-is-learning/thinking-locally-with-signal...
To be fair by that metric Vue has the fastest now with its core built with Alien Signals. Raw reactivity benchmarks don't actually show very much because these systems are so fast that the quickest to the slowest reactive library doesn't even make a dent on a test that says render the DOM.
And I say this as a benchmark enthusiast (and as that benchmark actually was crated by Milo from the SolidJS core team as part of our 2.0 research)
It isn't necessary. Solid has a similar custom renderer, with Pixi, three.js, terminal, etc... integrations. Solid is actually used a lot in embedded applications since it is low memory and performant. It powers Comcast's TV application applications like Peacock.
I'm curious which part of laziness are you concerned with? Is it delayed execution in events? It is just most lazy things run almost immediately during creation anyway, and on update everything is scheduled anyway. The only lazy thing we are looking at is memo's which while impactful isn't that different as the creation code runs.
I guess the push/pull propagation is harder to follow on update then simple multi queue but in complex cases we'd have a bunch of queue recursion that wasn't simple either.
Ironically, mechanically Vue and Svelte historically were much closer to React. Vue has a similar VDOM and Svelte while compiled still had a rerun component model.
It was only the past year about 6 years after Solid showed the way Svelte 5, and Vue Vapor got away from that and now compile down to what more or less Solid has been doing all along.
Of course this is under the surface. But in many ways while Solid itself has stayed relatively small it has profoundly impacted the rest of the ecosystem in a way we haven't seen since React. From Vue, Svelte, to Angular, Preact, and Qwik all using Signals now. The average user of these frameworks probably has no idea but everyday all the non-React frameworks work more and more like Solid.
I wonder how long by comparison you would have had to wait for React to fix a bug of that nature. Obviously no comparison on maturity given difference of user base size, especially 3 years ago. I appreciate you sharing as I think stories like that are good example of responsiveness of the project.
Low Commit count suggests nothing other than maybe lower traffic. I've been able to keep issues the main repo under 50 issues most of its life. I admit work towards the next major version has let this slip upwards. Also effort is split among multiple repos. Repos where I'm far from the biggest contributor. The core is small and manageable. Which is a good place to be 9 years in (7 of those open to the public).
Yeah exactly 7 years tomorrow. Wow time flies.
So excited for this. SSR with Astro is a gamechanger which opens up its usage to so many different avenues. Great strides with framework interop too. Named Slots really closing the gaps.
And of course any framework where SolidJS can shine so bright is going to be the top of my list.
Congratulations on an amazing release.
So excited to see what you all have done here. trueadm is the creator of Inferno, and has a great eye for performance. Can't wait to dig in.
It does. Just referential check. Our reactivity is nested and we don't want blow out everything so even though there is read/write segregation and immutable interfaces the internals are mutable. In so sorting looks at referential equality, and nested updates don't even trigger list diffing.
Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.
It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.
But those dependencies would be static. This goes beyond that. I won't call hooks flawed, they are suitable for React's model, but looking at what reactivity does is a different sort of thing. It is a subtle difference at first.
Mostly except there is no VDOM, the reactivity applies right down to the DOM binding. And it predates Hooks and Vue's Composition API.
Yep. Looks sort of like the Solid example in the article. It's basically my auto-response to Svelte syntax. Once you do anything in Svelte it is more or less the same thing.
Just different priorities. In Solid you can take that code as is in the component and hoist it out to a function above and presto.. store. It's all the same thing everywhere. Same patterns, same usage, same building blocks. No new APIs, no new syntax.
It is nice when first learning not to worry about Svelte Stores and use the convenient syntax. It is also nice to learn something once and use it everywhere.
Or Vue either to be fair. Similar rules in the Vue's setup function. It's how reactivity works in JavaScript. Basically don't destructure or access values out of of primitives or JSX. That's basically the gotcha.
Unfortunately it's the price you pay for portability thus far. You can build your own language around this like Svelte but then composability is limited (need to rely on other mechanisms). You can make the updates coarser grained like React but then you need a different mechanism(like VDOM diffing) to apply updates granularly. I imagine this situation improves in the future but we haven't gotten there yet.
There are a lot of React state libraries that do similar things with Proxies. I think the part that is not as emphasized is how that reactivity extends to the view. Instead of re-rendering components it uses that knowledge to directly update portions of the DOM. So while MobX, Valtio, Jotai, Recoil etc localize change in React, they still feed into the whole VDOM React cycle, instead of just updating exactly what changes. It's not a characteristic of these libraries but the fact they feed into React.