It's awesome to see performance-oriented projects to find their way to SolidJS(https://www.solidjs.com). So satisfying to see success stories like this one. Great work.
Congrats! One nit I have about SolidJS documentation is that it doesn't have a clear path for "migrating from React" which I take it is probably actually important to you given how similar SolidJS looks to React and how much faster it claims to be. Also might be good to include a section on how to interop with existing React libraries -- even if the answer is that you can't.
And it might be worth putting in your HN profile that you are the creator of SolidJS. :)
Wow, I just read about Solid for the first time, and I'm very impressed at the API design. I love how it's actually a fully reactive data flow thing, but it looks and feels like React Hooks.
The other reactive/observable-based frameworks I've seen (eg Cycle) very much put the observable streams center piece, and I always felt that was distracting, and that nuances about how the underlying observable stream library worked quickly got in the way.
Solid still puts the components firmly at the center, just like React, but replaces React's state concept by fully reactive observable state, called "signals". You use them pretty much like you useState in React, but deep inside it's an observable stream of changing data, and you get all the finegrained update control that comes with that.
Also, I love how noun-heavy it is. Resources, tracking scopes, effects, signals. It's just like how React moved from "do this thing after the component updated" to "ok we have this concept called an effect", but extended to more topics such as dealing with async data loading, when exactly a signal is observable, etc.
React Hooks are the reason why I want to stop using React. They are confusing and seemingly magical, compared to lifecycle methods that make a ton of sense. While I agree they can make complex things easier, they are also incredibly easy to get wrong, as they are order dependent.
Reading the Solid landing page, what I see is "Solid takes the most confusing part of React, and runs with it."
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.
I'm struggling to find out how it actually updates the DOM. The way that re-rendering happens is clear but it looks like the top-level function just returns a JSX.Element. There is no explanation how this is efficiently rendered.
Also how are mid-level invalidations handled? For example if I update a list to remove one element do the other elements get re-rendered or are they cached?
It might be because I am browsing the docs in mobile but I find them hard to navigate.
I've been keeping an eye on your work for a long time now. We're a mobx shop so I was hoping to see you explore the ideas you had around that a little more (https://github.com/ryansolid/mobx-jsx).
I like and know where I'm at with React, but bringing a beginner through it recently definitely made me re-appreciate how nuanced it is. Also, you have to do a bit of voodoo to get good performance, and when you do the intention of the code vanishes pretty quickly.
For someone using React on top and mobx stores in the background (say 50k LOC all in), how big of a task would you say it is to move to something like Solid?
congrats on the performance. But I just hope that React will quickly catch up and improve in terms of speed & performance. It is really tough to learn a new framework every few months.
It's unlikely. Solid has had this performance profile since 2017. React hasn't really budged. Fundamentally different approach. There are different types of performance to explore but raw performance for small things is not something React is going to "catch up" on. Might be worth a read: https://javascript.plainenglish.io/javascript-frameworks-per...
I hope React won’t have all of those gotchas which make a good year of experience necessary when training a junior, until he migrates to a job that pays for his upgraded skills… Cost of skills is a thing.