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

141–150 of 190 posts

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

#141

Post by ryansolid »

hombre_fatal wrote: post #113
fastball wrote: post #33

Earlier quoted context omitted.

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…

One interesting benefit React's tree + diffing system is that you can use a custom reconciler to do more than just create and update DOM nodes. And a good example of that are React libraries that turn stateful imperative APIs into declarative nodes: - https://r3f.docs.pmnd.rs/getting-started/introduction - https://github.com/pixijs/pixi-react

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.

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

#142

Post by owebmaster »

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…

> React core has been exactly the same as it was ten years ago

Are we not considering Hooks core yet?

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

#144

Post by ativzzz »

gitroom wrote: post #90

I think it's kinda wild how much more fun I have with Solid after slogging through React stuff all day - you think tech like this actually stays small by design or is it just hard to get people to switch?

It's likely that your React codebase is huge (I assume it's for work) and you're messing around with a toy Solid project. I'm sure once you get to the same scale and complexity of a Solid project, you'd feel the same way about whatever next framework you find

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

#145

Post by erikerikson »

steve_adams_86 wrote: post #65
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…

Is laziness intended to offer primitives for suspended UIs? I haven’t used Solid for a while and can’t recall if there’s a Suspense counterpart already. If not, this seems like a reasonable feature to add. It’s a familiar and pretty intuitive convention

Looking for this? https://docs.solidjs.com/reference/components/suspense

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

#146

Post by erikerikson »

exceptione wrote: post #111
voat wrote: post #110

Earlier quoted context omitted.

Most of the modern front end frameworks can handle those use cases. Solid, Vue, Svelte all have capable SPA frameworks and component libraries

I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.

https://suid.io/ is MUI for SolidJs

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

#147

Post by MrJohz »

seanwilson wrote: post #138
MrJohz wrote: post #61

Earlier quoted context omitted.

Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime. Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new file…

> Vue uses single-file components, SolidJS uses JSX. You can use Vue and JSX, it's mentioned on the official site: https://vuejs.org/guide/extras/render-function

That's true, but it's not usually recommended for most cases. You lose out on a number of optimisations, and I don't believe it'll be directly supported for vapor mode when that comes, although it looks like there's a plugin that will get them to play nicer with each other.

If you want JSX and signals, I suspect you'll get more out of just using SolidJS, as that framework is focused on working well with JSX directly.

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

#148

Post by TimTheTinker »

hombre_fatal wrote: post #123
zamalek wrote: post #38

Earlier quoted context omitted.

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.

I think it's just the lifecycle of craftsman tooling in general. When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools. Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.…

It's also easy to confuse problems that arise from failing to adequately manage the gotchas with problems inherent in the tool itself. There's a subtle distinction there that's easy to miss, especially for those with a blame-the-system sort of attitude (which I don't entirely fault).

One company I worked for had a very slow frontend. It was common there to blame the slowness on React. "React is just kind of slow."

Another company I worked for had a much larger React-based frontend, and it was fast-loading and snappy by comparison.

The difference is that the second company had much more well-established good practices in its design system, the codebase, the enforced lint checks, and the general knowledge of its engineers. They avoided performance traps that caused multiple renders of things. (The first company's frontend would render a given screen 12+ times for some state changes.)

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

#149

Post by ManBeardPc »

division_by_0 wrote: post #114
ManBeardPc wrote: post #81

Earlier quoted context omitted.

SolijS is just JS without much magic. It's simple, small and very fast. You can use signals and effects outside of components and it just works. You can even use a signal from the global scope within a component. Tracking of signals for effects and derived values is automatic. It looks very similar to React, but it's better in every way. Honestly the first time I'm happy with this kind of library. Don't need much mor…

Yes, Solid is very fast, but Svelte's Signals implementation seems to be even more performant. [0] I just loved the simplicity of using $: for deriveds and effects in Svelte 3 and 4. But after building a correlation matrix [1] and a work project with Svelte 5, I have to say that I really like it. [0] https://github.com/sveltejs/svelte/discussions/13277 [1] https://covary.xyz

Thanks for the info. I’ll definitely check Svelte 5 out.

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

#150

Post by mightyham »

ryansolid wrote: post #86
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…

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…

Wow, I never imagined you would respond to my comment, a little embarrassed ngl :D

I understand that under the hood Solid's reactive system is not quite simple; though, the mental model needed to use it, is very simple, which I greatly appreciate when building complex application logic on top of it. That's really my main concern: that one-way "push" semantics are easy to follow and think about, and adding new mechanics complicates that picture. It seems deceptive that what presents itself, at least conceptually, as just a value access, might now cause arbitrary code execution (another way of putting this is that it feels like it violates the principle of least astonishment).

As I mentioned before, I also haven't run into situations in practice where lazy memos seem like a desirable behavior. If I initialize a derived value, it's because I plan to use it. If some computation needs to be "delayed", I place it inside an if statement with a reactive condition, for instance, createMemo(() => shouldCompute() ? computeValue() : undefined).

All that's said, you've done a fantastic job with Solid. I hope you continue to innovate and prove my objections misguided.

Post reply on HN