ryansolid

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.

Yeah RSCs are another approach I'd say that are playing with these sort of approaches. Other notables include:

Marko: https://www.markojs.com Astro: https://astro.build

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.

What does a reusable (ie import from another file) `useAutoCounter` look like in Svelte?

I'd also look at other repos. Admittedly for the core code it has been mostly me. I think there is an intimidation factor. When you create a library this performance oriented it is hard to get people comfortable working on the core.

But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors

We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.

Yeah this is correct. The trick to this is that the subscriptions happen in our JSX and hooks. And really is just a nested tree of `createEffects` if one ever re-evaluates or is disposed it releases its child computations. So while the lifecycle isn't tied to components it is still hierarchically structured. Ie.. places where logic can branch becomes the owning scope, like conditionals or loops. So Signals like count don't really matter where they live and will live as long as in scope or referenced, the rendering still largely defines how long things are around.

Reactivity like this predates React Hooks. It doesn't have the hook rules/stale closures etc... No dependency arrays, useRef, or useCallback. It's a very powerful model and very different. The similarities are surface level but aren't without benefit. Composable declarative data patterns, read/write segregation, traceable state dependencies.

Some people position it more like, "Solid makes Hooks the way they should have been in React". Personally understanding how React works this doesn't make sense. But I think it might be helpful for people just approaching the framework.

This is the article series for you (I wrote it so I'm biased): https://dev.to/ryansolid/a-hands-on-introduction-to-fine-gra...

More than likely it's the lazy loading of the REPL. Those code editors are heavy and when they scroll into view they need to load. If we load up front it would drastically tank the load performance for people just visiting the site. It's possible on mobile we should opt for a click to load strategy.

There is very little we can do about this once we do go to load, it's just the nature a heavy fully featured editor like Monaco.

Hey Solid's reactive system uses Signals which are different than streams but work in similar use cases. Streams are slightly more oriented to transformation than synchronization. Most stream libraries could be used with Solid with a bit of an adapter on the end to connect to the templates as they are a good tool for managing global state.

All that being said. If you are happy with Mithril stick with it. It sounds like it's done everything you needed. I have a lot of respect for it's minimalist approach and its author is one of the most insightful and helpful people I've come across since getting into JavaScript frameworks.

If you are interested in trying something different. Check out our tutorials on the site and see how you feel about it. It is a little bit different type of framework.

Something you don't need to think about until well, you realize reactivity leaves templates and you need to write a store. Or that you have large data and need things to only update piecewise. Or you need to hoist things out into functions. Svelte has done an amazing job with its compiler but there are considerations you need to understand with its reactivity.

Solid does not have Hooks or Hook rules. They look similar but execute more similar to say Svelte. Although Svelte still is about Component re-renders and Solid's reactivity is more granular hence the performance improvement.

This area of DSLs is very superficial for the most part. I think people have preferences and I'm exploring both sides between Marko and Solid but saying things like unintuitive I think mischaracterizes things. Maybe explicit, transparent, transferrable, and composable are better adjectives that apply more to Solid than to Svelte that you can use in the future.

Solid's diff algorithm generally is faster(or atleast very comparable) than Mithril's. We test very well in list benchmarks like: https://krausest.github.io/js-framework-benchmark/current.ht.... We are also fast at node creation using pre-compilation to prepare the nodes in a way that can be created more efficiently.

It's a bit like MobX but instead of re-running full components or subtrees it contains the updates granularly. Picture if your renderer was just MobX Autoruns wrapping specific DOM updates as depended upon. In so because the reduced of need for diffing and the compiler that transforms the JSX to this you can author components in a normal way yet get incredible performance.

Hmm.. Remix is based around their router. And a nested router is what we need to for Solid (see Solid App Router https://github.com/solidjs/solid-app-router). I think the challenge is that we don't render like React. Not at all. I've found most cases where that assumption exists to be incompatible.

That being said the work has already started on a starter with Nested Routing/Automatic File Based Routing + Code Splitting/Parallelized Data Fetching/Streaming SSR/Multiple deployment adapters. We're given it the same focus on performance that we've given the rest of Solid.

Here is the recent Vercel Edge Function demo we made with it: https://twitter.com/RyanCarniato/status/1453283158149980161

It's a fair question. Pre React Hooks I expected the proxy plain object approach to be more common. We definitely want consistency regardless if component consumer passes signal or literal, so I went that way. There are cases like with spreads where they are actual proxies too. But probably could have made all props are functions work and have them work with combination of proxies as well things just didn't play out that way.