Ok, you've got my attention with documentation like this
const [first, setFirst] = createSignal("JSON");
const [last, setLast] = createSignal("Bourne");
Solidjs: Simple and performant reactivity for building user interfaces
31–40 of 190 posts
Re: Solidjs: Simple and performant reactivity for building user interfaces
#32Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc I personally don't like that direction so looking forward to exploring new frameworks. What I've generally liked about React/Next setups is that the code is generally explicit and less magic (I also have gripes with hooks feeling like magic). Things like Vue/Svelte wh…
Never did I ever once think React would one day be compared to PHP.
Reading that post the other day and seeing modern terminology being applied to old backend rendering was quite the experience. "Imagine on initial page load it returns the complete screen UI with all props and components already hydrated".
I remember those days but I remember some of the bad as well. I really started to hate that every UI change in the template/HTML meant changing the page controller to handle the new data. I specifically remember wanting some technology that allowed the UI to dictate what data it needed.
The pendulum swings though and it seems we are reversing course lately. Perhaps we land on a solid middle ground finally.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#33Has anyone used both Solid and Vue? How do the two compare?
If you want to compare Solid to Vue, I think it is easier to just compare React to Vue. If you like React better, then you can compare React to Solid and see which you prefer. SolidJs is 90% similar to React in terms of DX, with only a coupler major differences.
Things the same as React in Solid: function-based components with hooks, JSX, overall "JS-first" (vs Vue which I'd describe as "HTML first")
Things different from React in Solid: "signals" instead of state (observer pattern), built-in components for rendering control flow (, , etc), direct manipulation of the DOM. All these differences combine to the overall main difference, which is that React kinda revolves around an immutable re-render cycle where a function is re-run in its entirety to create a new vDOM representation each time, while Solid renders a component once then only selectively re-reruns parts of the component / mutates the DOM.
So I'd say pretty much the only similarity between Vue and Solid (contrasted with React) is the built-in components for control flow. Everything else is the same differences or similarities that Vue has with React.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#34Earlier quoted context omitted.
Nothing about the RSC format is privileged in the React client (i.e., react + react-dom). You can always make your own serialization format as long as it can represent React elements and promises somehow. You can of course also use the RSC wire format and pin to a specific client version (or vendor/fork it) but it’s not a stable format today because it’s not clear if many people would use one and we want to leave roo…
That's fair, though IMHO some marketing from Vercel does make it difficult for someone not versed in the internals to understand what is "privileged in the React client" and what is not. That's their prerogative as a leading maintainer, of course. And completely understand that freezing a format causes all kinds of difficulties, and semver alone doesn't solve for the resulting community frustration. So I understand w…
It’s fair, the docs could be better! And there are certainly subtleties with hooking up the router and bundler and everything. However I will say that really there is no funny business going on.
Basically the entire elaborate RSC apparatus just ultimately outputs a tree of plain React elements with promises and to make it streamy. Sounds like groundbreaking simplicity to me! I kid a bit but really I’m not sure that the RSC wire format is any easier as an output target than the existing public React client API.
Maybe I should make a little demo to show that.
But anyway the point is that the wire format is an implementation detail because the two sides of the wire are actually the same program. Even if they’re running on two different computers.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#35So is Solid kind of like React but easier to use?
Solid is fundamentally different from React - it compiles reactive primitives to direct DOM updates with no virtual DOM or re-rendering, whereas React re-renders components when state changes.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#36Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future. This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points…
> Having used Solid on a largish web product for over a year I am curious about your experience in this regard. I've been aware of Solid for quite a while (and plenty of other non-React alternatives that on paper seem "nicer") but the problem I usually quickly run into after exceeding the complexity of a contrived demo app is the ecosystem not yet having a number of components, library wrappers, integrations, etc. th…
Not op, but I converted an online card game etg.dek.im from React to Solid. What helped is that I don't use any of other React libraries
Used to use redux, got rid of it. Used to use react-spring, got rid of it
Re: Solidjs: Simple and performant reactivity for building user interfaces
#37I love Solid so much. It has feature parity with React and is faster. However, most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term.
React is unreadable and bloated with 20,368 commits and seemingly unstable with the maintainers always pivoting it around. I like it's semantics, but don't want to deal with updating it long term as a dependency.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#38Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future. This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points…
React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#39Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future. This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points…
> Having used Solid on a largish web product for over a year I am curious about your experience in this regard. I've been aware of Solid for quite a while (and plenty of other non-React alternatives that on paper seem "nicer") but the problem I usually quickly run into after exceeding the complexity of a contrived demo app is the ecosystem not yet having a number of components, library wrappers, integrations, etc. th…
I've found the ecosystem to be perfectly serviceable for every complex piece of functionality I needed to bring in: remote state, forms, tables, and routing, come to mind. Complex state management can easily be handled using the library's standard reactive primitives and the community "solid primitives" project has a ton of well made utilities so you don't have to reinvent the wheel for common use cases.
I'm not going to sugar coat it though, SolidJS is not necessarily a batteries included ecosystem. There is a severe lack of components/component libraries. Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#40Nice, but Mikado is faster
Deleight is faster than Mikado.
https://krausest.github.io/js-framework-benchmark/current.ht...