Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solidjs: Simple and performant reactivity for building user interfaces

solidjs.com

Post reply on HN
Print view View original

21–30 of 190 posts

Re: Solidjs: Simple and performant reactivity for building user interfaces

#21

Post by sophiebits »

btown wrote: post #13
thomasfromcdnjs wrote: post #4

Portions 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…

One of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop betw…

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 room to improve the format as new optimization opportunities arise.

Though you do lose a lot of the magic if you don’t have JS on the server at all. Part of the core proposition of RSC is that it’s easy to move logic across the boundary as your app evolves. What goes over the wire can be a performance decision instead of a “that’s too much of a pain to move to the other side I’ll just leave it” decision. For that reason I’d generally make a thin “backend for frontend” in JS that talks to an Erlang/Rust/etc backend. It’s conceptually part of the frontend but runs on your server.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#24

Post by leeoniya »

i'm personally a fan of ivi-js.

it has blindingly fast perf (edges out Solid by a bit), top-down data flow, with fine-grained diffing, tagged template syntax, real closure state without rules-of-hooks weirdness and waste, super efficient mem use, and no special reactive primitives like signals/observables/proxies to get that performance, so you could use it with complex serialized/able state over wire (which is not something you can do with reactive primitives).

https://github.com/localvoid/ivi

Re: Solidjs: Simple and performant reactivity for building user interfaces

#25

Post by math_dandy »

technion wrote: post #17
chabska wrote: post #14

Earlier quoted context omitted.

> I personally don't like that direction so looking forward to exploring new frameworks. Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core. Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases…

Much of the official documentation now refers to server components as the "right" way to do certain things. Cra is end of life, with the replacement nextjs being heavily biased towards server components. Your tooling certainly has changed in that you won't use cra any more, and I wouldn't agree that this direction does not detriment previous use cases.

I view create-vite-app with React presets as the spiritual successor of create-react-app, rather than NextJS.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#26

Post by btown »

sophiebits wrote: post #21
btown wrote: post #13

Earlier quoted context omitted.

One of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop betw…

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 why the decisions were made - it's just all a bit foreign to me compared to the groundbreaking simplicity of React's APIs in its earliest days, where if you understood a render cycle the entire world was your oyster. The internals of the renderer were always fine to be "off limits" - but wire formats just feel quite different to me.

(Also, just want to say you're an absolute hero of mine, and my hopefully-gentle nudging on this is because I love everything the React team has created, and I want React to see its full potential!)

Re: Solidjs: Simple and performant reactivity for building user interfaces

#28

Post by mvdtnz »

chabska wrote: post #14
thomasfromcdnjs wrote: post #4

Portions 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…

> I personally don't like that direction so looking forward to exploring new frameworks. Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core. Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases…

Really? So class components are still first class citizens and play well with existing ecosystem code?

Re: Solidjs: Simple and performant reactivity for building user interfaces

#29

Post by josephg »

thomasfromcdnjs wrote: post #4

Portions 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…

I've been using solidjs (via solidstart) for awhile on a medium sized project.

> Portions 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

Solidstart definitely pushes you to use their magic server functions. I used them at first - but increasingly I've been moving back to writing a normal, real REST interface on the server side. It still works fine, its just a few more lines of code to do it yourself. The biggest benefit is that I can control my HTTP verbs and headers. This lets me set up caching correctly, both in the browser and any intermediate caches.

> Things like Vue/Svelte where they mash together css and js in the same file if you want kind of turns me off.

Solidjs doesn't mash css and JS together. You usually use normal, real CSS or CSS modules. Eg:

    import styles from './style.module.css'

    function BannerComponent {
      return Banner
    }

Re: Solidjs: Simple and performant reactivity for building user interfaces

#30

Post by dkh »

mightyham wrote: post #2

Having 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. that I use all the time.

Have you found the Solid ecosystem sufficient for whatever your needs are, is it fundamentally easier with Solid to integrate things that don't exist yet, or did you go into it less spoiled/tainted as I by reliance on React's ecosystem?

Post reply on HN