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

Solid – A declarative JavaScript library for building user interfaces

github.com

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Solid – A declarative JavaScript library for building user interfaces

#141

Post by ryansolid »

sreekotay wrote: post #126

One minor thing I might consider is more examples with animation in UI --- it's a place where most apps want to go but have trouble doing elegantly/performantly.

I agree completely. I left an early github issue open with some examples. It just isn't my forte. I've worked with frontend guys who were mostly CSS ninja's and we never relied on framework mechanisms beyond applying some classes etc. I just lack the base knowledge to know what the expectation is here. I know Svelte has a very impressive system. I could look at doing something similar with Solid just not sure where to start.

Re: Solid – A declarative JavaScript library for building user interfaces

#142

Post by aboodman »

ryansolid wrote: post #128
saiojd wrote: post #121

I've been playing around with your library for the last hour and so far it's excellent, pretty what I had hoped for after working with React for a while. The performance of individual renders is one area of improvement but I think the main contribution is the clarity the update model provides. React works well until you try to avoid re-rendering and then it really falls appart. For example, updating a context re-rend…

I do return a proxy. It's just readonly. I really like the unidirectional data flow and explicit read write segregation of react. This adds so much control without having to add Framework like control mechanisms. I know it isn't easy, but it something that makes the solution elegant in the end. I think that passing data should also mean the choice of passing the ability to update it. That is a problem I have with alm…

> I think that passing data should mean passing the ability to update it.

I'm pressing this up triangle as hard as I can, but sadly it still lets me upvote this only once.

Re: Solid – A declarative JavaScript library for building user interfaces

#143

Post by aabbcc1241 »

ryansolid wrote: post #13
obilgic wrote: post #11

If your library/framework/etc's goal is to make life slightly better, just don't do it. This just looks like React.

Fair enough. Keep in mind I've been working on this for close to 5 years. Basically around the time I realized KnockoutJS was going to die out and React was for good reason going to win. Here is an article about why this library exists: https://dev.to/ryansolid/why-solidjs-do-we-need-another-js-u...

This article is well written. Great job!

Re: Solid – A declarative JavaScript library for building user interfaces

#144

Post by ryansolid »

sreekotay wrote: post #122
ryansolid wrote: post #97

Earlier quoted context omitted.

With React your Component re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Component is a basic function that executes once closing over state getters with its Hooks, which are the only thing that run over and over as needed when state changes.

Very cool work! And great performance. Funny - during quarantine I've been playing with the OPPOSITE. A no build, runtime only reactive JS engine... Would love to compare notes - you can check out (very much WIP progress) at https://github.com/sreekotay/reefer It's been only a few weeks of fun... but REALLY interesting problem space. I use a DOM memo-ish approach to help with performance...

Awesome I think so too. I love exploring this space in general. It's really interesting to see how you can model problems this way. Reactivity isn't a solution to a single problem but a way of modelling any problem

Solid actually can work runtime only too but I do put most of my effort on the compiler since I can use it to overcome most of the classic shortcomings of the reactive approach performance wise (and DX wise) with a bit of consideration.

Re: Solid – A declarative JavaScript library for building user interfaces

#145

Post by saiojd »

ryansolid wrote: post #137
saiojd wrote: post #133

Earlier quoted context omitted.

I'm not sure I understand your argument in favor of setState correctly. By splitting the state into two parts (a read-only view, and a setState function to update it), isn't the opposite being accomplished? It is now possible to pass the data without passing the ability to update it, or vice-versa. Which could very well be desirable but could be accomplished by other means (i.e. leaving to the parent the choice of pa…

I mean it's basically the same thing as you do with React. You create lens functions more or less to handle get/set over the state object. Solid's setState has a lot more capability than React's handling nested updates with an ImmutableJS or Immer inspired API. The clever part here is immutable libraries already have API patterns to describe mutation so I just apply them here. So instead of spreading everything and c…

That makes sense. It is mostly the O(n) rerendering which is expensive, not the array copy. With regards to superficial/syntactic issues now, I just don't see the advantage of:

`setState('list', state.list.length, newItem);`

over

`list.push(newItem);`

Considering that the two operations can be otherwise equivalent when using proxies (from what I understand).

Re: Solid – A declarative JavaScript library for building user interfaces

#146

Post by saiojd »

ryansolid wrote: post #135
saiojd wrote: post #134

Earlier quoted context omitted.

Thanks, that makes a lot of sense (basically Mobx but fine-grained). When I mentioned diffing, I meant for updating state objects like lists. Your ` ` element only updates if a new list is created, but only re-renders the changed elements. I assume this is accomplished by diffing the old and the new list?

Yes you are correct. Use diffing here actually very similar to VDOM libraries. It was more performant(and consistent) than just propagating the change purely through manipulation of a proxy. Especially if you consider things like batching.

Thanks. Batching was more efficient with diffing because you can avoid keeping track of which array indices changed within the same batch?

Re: Solid – A declarative JavaScript library for building user interfaces

#148

Post by ryansolid »

saiojd wrote: post #145
ryansolid wrote: post #137

Earlier quoted context omitted.

I mean it's basically the same thing as you do with React. You create lens functions more or less to handle get/set over the state object. Solid's setState has a lot more capability than React's handling nested updates with an ImmutableJS or Immer inspired API. The clever part here is immutable libraries already have API patterns to describe mutation so I just apply them here. So instead of spreading everything and c…

That makes sense. It is mostly the O(n) rerendering which is expensive, not the array copy. With regards to superficial/syntactic issues now, I just don't see the advantage of: `setState('list', state.list.length, newItem);` over `list.push(newItem);` Considering that the two operations can be otherwise equivalent when using proxies (from what I understand).

It comes down to control and immutability. I know not everyone agrees with this but I believe it's fundamental.

You can use the "Immer" syntax of setState if you want:

setState(s => { s.list.push(data); });

But in some cases it is more expensive. Like a splice will per row will trigger the proxy to tell you they've all shifted a position. Where as just setting the array only hits the proxy once. Sure Solid batches the updates from the call but it's still unnecessary tracking. Solid lazily decides whether state should be made into a reactive atom based on whether it is referenced in a tracking scope.

Re: Solid – A declarative JavaScript library for building user interfaces

#149

Post by ryansolid »

saiojd wrote: post #146
ryansolid wrote: post #135

Earlier quoted context omitted.

Yes you are correct. Use diffing here actually very similar to VDOM libraries. It was more performant(and consistent) than just propagating the change purely through manipulation of a proxy. Especially if you consider things like batching.

Thanks. Batching was more efficient with diffing because you can avoid keeping track of which array indices changed within the same batch?

Yes and keeping the order of application. I actually played with this for a bit. Early Solid let you basically codify mutations you could send in as data. I thought it was interesting to do something like Redux where instead of producing the next state you produced the mutations that would be applied, and then applied them at a granular level instead of diffing. But when you add time into the picture you actually have keep track of more. I'm not saying it's impossible to tackle this just the people I know who have been working at this always hit limitations where they need to fall back to diffing anyway. I think it would take some doing to determine where the book keeping cost would be worth it. It is rarely as simple as more granular is better.

Re: Solid – A declarative JavaScript library for building user interfaces

#150

Post by christophilus »

julianeon wrote: post #125
christophilus wrote: post #48

I recently rewrote a small toy project from Preact to Solid. It went from spinning my fans and consuming over 25% of my cpu to practically idling. Solid is legit. I could have optimized my Preact, but I didn’t have to think of it with Solid. Same is true of Svelte. Edit: I see the author is here, and lots of typically negative comments are being thrown at him. Ignore them and keep up the good work! We need people lik…

This sounds like a really atypical project. Consuming 25% of your CPU is a lot! I hear people mention those kinds of numbers only for Slack, which does have a lot of functionality. I'd just point out that for the average project, the main advantage is that with something like Solid or Svelte, it will load in less than a second, vs. a few seconds for React, especially for something simple like a blog where you don't w…

It is atypical, yeah. It's a speed-reading app, so it flashes a new word on the screen every nth of a minute, where n is how many words per minute you want to read.

Still, I'm tired of using a normal web application and feeling the UI lag when I type, etc. I suspect that if you start off with a project like Svelte or Solid, you'll have a longer runway on your app before you get to that level of suck.

Post reply on HN