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

Solidjs – JavaScript UI Library

solidjs.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Solidjs – JavaScript UI Library

#51

Post by eatonphil »

nawgz wrote: post #8
eatonphil wrote: post #7

> In Solid, props and stores are proxy objects that rely on property access for tracking and reactive updates. Watch out for destructuring or early property access, which can cause these properties to lose reactivity or trigger at the wrong time. From the docs; does SolidJS provide a way to lint or warn on this? I've been getting more and more scared of destructuring and ... copying recently since, for example, you l…

> I've been getting more and more scared of destructuring and ... copying recently Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly. In reality though, assuming you are destructuring to pass it down a tree (and not around the app), this usually just means that you lose the optimizations of only rendering some part of the subtree and render your whole subtree more often, w…

> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly

Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype.

So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning.

I want to be able to copy objects with a nice syntax but still have them retain their prototype.

Since no one warns you (TypeScript anyway) about losing your prototype it makes me worry about this everywhere because who knows which objects weren't meant to lose their prototypes.

Re: Solidjs – JavaScript UI Library

#53

Post by joshum97 »

eatonphil wrote: post #7

> In Solid, props and stores are proxy objects that rely on property access for tracking and reactive updates. Watch out for destructuring or early property access, which can cause these properties to lose reactivity or trigger at the wrong time. From the docs; does SolidJS provide a way to lint or warn on this? I've been getting more and more scared of destructuring and ... copying recently since, for example, you l…

I’m working on eslint-plugin-solid for this reason, and while I haven’t implemented this yet (it’s complicated), it will eventually warn when something is wrong with reactivity in general.

Re: Solidjs – JavaScript UI Library

#55

Post by pier25 »

deepstack wrote: post #48
p2hari wrote: post #45

Earlier quoted context omitted.

Oh,I agree so much here. It was 2 years back when I had looked at SolidJS. It was a simple project and had Bootstrap for a couple of pages and instead of JQuery or Mithril, I put in SolidJS. Was stuck on few reactive issues. Ryan was so quick to help me and also explain few things which really helped me.

Interesting how does this compare to Mithril? I have yet find anything that is more performant than Mithril. Never heard of solid. How is it?

Mithril is reasonably fast, but there are plenty of faster options like Solid, Inferno, Preact, or Svelte.

https://krausest.github.io/js-framework-benchmark/current.ht...

IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB.

It's really verbose though compared to Svelte.

Re: Solidjs – JavaScript UI Library

#56

Post by mekkkkkk »

eatonphil wrote: post #51
nawgz wrote: post #8

Earlier quoted context omitted.

> I've been getting more and more scared of destructuring and ... copying recently Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly. In reality though, assuming you are destructuring to pass it down a tree (and not around the app), this usually just means that you lose the optimizations of only rendering some part of the subtree and render your whole subtree more often, w…

> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype. So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning. I want to be able to copy objects with a nice syntax but…

Destructuring only really makes sense for simple struct-like data structures. If you are worrying about prototypes you are destructuring the wrong things. Duplicating class instances is almost always something that you'll need to do manually or through serialization in OOP afaik.

Re: Solidjs – JavaScript UI Library

#57

Post by richeyryan »

dzonga wrote: post #47

ryan, is a cool guy. but I feel like a lot of work they're doing on marko, will be much better than solidjs. solidjs api is non-intuitive, same as the reactive system say compared to svelte. Hooks are already a bad idea in react, for reasons I will not expand on. And having the same concept in solidjs isn't progress at all. Svelte nails reactivity, it's something you don't think about.

I think you need to take a second look at Solid. It isn't subject to the same "rules of hooks" as React so hooks are really just functions that return reactive units. You could argue writable and readable are just hooks for creating stores. It's reactivity is fairly similar to Svelte from there. There are stylistic choices with Solid choosing a function style and Svelte abstracting that with proxies and allowing a mutation style but otherwise how the reactivity works is close.

I do agree that Marko is quite promising. I think quite a few sites that need server rendered markup and progressively enhanced features could be implemented more simply in Marko than the equivalent solutions with React, Svelte or anything else.

Re: Solidjs – JavaScript UI Library

#58

Post by eatonphil »

mekkkkkk wrote: post #56
eatonphil wrote: post #51

Earlier quoted context omitted.

> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype. So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning. I want to be able to copy objects with a nice syntax but…

Destructuring only really makes sense for simple struct-like data structures. If you are worrying about prototypes you are destructuring the wrong things. Duplicating class instances is almost always something that you'll need to do manually or through serialization in OOP afaik.

All I did was try to put some helper methods on data classes. :D But yeah clearly I'm going against the grain.

Re: Solidjs – JavaScript UI Library

#59

Post by cloverich »

skrebbel wrote: post #44

(repost from the Asciinema thread, this comment feels more on topic here) Wow, I just read about Solid for the first time, and I'm impressed at the API design. I love how it's 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) put the observable streams center piece. I always felt that was distracting, and that nuances about h…

By fine grained update control -- do you mean similar to mobx + react. I think "automatic change tracking" is the phrase I've seen thrown around. If so this was always the most appealing method for performant UI's for me. You have some conceptual overhead of dealing with observables, but in return you get to ignore the majority of performance -- components only update when the data they need to use changes, and you never have to manually specify it. Really nice for web apps that have a lot of mix and match screens (say, complex internal tooling that may have numerous components re-used ina variety of places).

Re: Solidjs – JavaScript UI Library

#60

Post by ryansolid »

cloverich wrote: post #59
skrebbel wrote: post #44

(repost from the Asciinema thread, this comment feels more on topic here) Wow, I just read about Solid for the first time, and I'm impressed at the API design. I love how it's 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) put the observable streams center piece. I always felt that was distracting, and that nuances about h…

By fine grained update control -- do you mean similar to mobx + react. I think "automatic change tracking" is the phrase I've seen thrown around. If so this was always the most appealing method for performant UI's for me. You have some conceptual overhead of dealing with observables, but in return you get to ignore the majority of performance -- components only update when the data they need to use changes, and you n…

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.
Post reply on HN