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

131–140 of 178 posts

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

#131

Post by jadbox »

hardwaresofton wrote: post #3

Solid is another smart-compiler, virtual-dom-less frontend component building library. If you're wondering how this is different from Svelte, the author has a Medium post on it[0]. [0]: https://medium.com/@ryansolid/javascript-ui-compilers-compar...

One thing the article doesn't really dive too far into is that Svelte is template driven, while Solid is more about React's jsx-drive-components. As I've used both style methods for years, I think I'm growing fond of Svelte's template approach as the best general purpose solution. This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. Being able to keep all that static code as close to vanilla web really helps to reduce other overall complexity, with the added benefit of being able to copy html with css from anywhere into my project, and then add dynamic behavior without "rewriting" basic html into jsx (which can lead to subtle bugs).

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

#132

Post by ryansolid »

amelius wrote: post #129
have_faith wrote: post #115

Earlier quoted context omitted.

There's usually no render function to call in these types of frameworks as far as I understand (my experience being a little Svelte). I imagine in your scenario the psuedo code to achieve what you want would be written. list2 = bubble_sort(list1) removeItem = () => delete list2[random index] ... The compiler will see a change to the list2 variable anywhere that removeItem is called and annotate the code to make the a…

Note that the item is deleted from list1. The framework should (I suppose) track that list2 depends on list1 through bubble_sort(). Are the dependencies implicit? Or should they be declared explicitly?

Generally implicitly either through proxy or get method read. Solid provides an explicit API as well.

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

#133

Post by saiojd »

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'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 passing a read-only or a mutable proxy). Settings aside the superficial issue of syntax, the main thing I dislike about the setState interface is for updating things like lists, where you need to perform a full copy just to insert one element. That being said I haven't yet looked into how exactly you handle lists.

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

#134

Post by saiojd »

atfzl wrote: post #123
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…

state changes are not tracked by diffing, it is much more interesting. You can read about it here https://www.atfzl.com/understanding-solid-reactivity-basics

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?

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

#135

Post by ryansolid »

saiojd wrote: post #134
atfzl wrote: post #123

Earlier quoted context omitted.

state changes are not tracked by diffing, it is much more interesting. You can read about it here https://www.atfzl.com/understanding-solid-reactivity-basics

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.

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

#136

Post by uryga »

EGreg wrote: post #74
olah_1 wrote: post #66

Earlier quoted context omitted.

My annoyance with that talk is he never compared Svelte with multi-threaded React. It was the natural next thing to look at but it was like “okay my point stands let’s move on” haha.

Well maybe we should compare apples to apples. With React you go down a rabbithole of workarounds around their initial concepts (like hooks) until you wonder why you chose it in the first place.

why do you consider Hooks a "workaround around [React's] initial concepts"?

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

#137

Post by ryansolid »

saiojd wrote: post #133
ryansolid wrote: post #128

Earlier quoted context omitted.

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'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 cloning you keep the mutation locality for performance but keep the control of immutability.

Also don't be worried about copying the array that much. I'm doing that in the JS Framework Benchmark and it's still about the fastest with 10k items. The real key is identifying where you don't need to update the list at all just the items in it. That being said you can do an update without copying the array like this:

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

Granularity of performance isn't a silver bullet. Being fine-grained doesn't necessarily make everything faster (especially creation). The power is that granularity is arbitrary so it can be maximized to the type of situation, completely independent of component structure.

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

#139

Post by ryansolid »

jadbox wrote: post #131
hardwaresofton wrote: post #3

Solid is another smart-compiler, virtual-dom-less frontend component building library. If you're wondering how this is different from Svelte, the author has a Medium post on it[0]. [0]: https://medium.com/@ryansolid/javascript-ui-compilers-compar...

One thing the article doesn't really dive too far into is that Svelte is template driven, while Solid is more about React's jsx-drive-components. As I've used both style methods for years, I think I'm growing fond of Svelte's template approach as the best general purpose solution. This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. Being able to keep…

We use JSX identical to a Template DSL more or less. We don't use JSX at all like React does. That's why Solid so performant. It does similar thing to Svelte. We don't compile it into HyperScript. You can copy and paste html with one exception (void elements JSX makes you close input tags etc). But otherwise I support all the standard stuff pre-adding the dynamic bits. Solid supports `class` and `for` and `style` strings etc..

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

#140

Post by ryansolid »

aabbcc1241 wrote: post #138

Solid looks like Surplus.js mix react.js

Yep more or less. I was working with Adam, Surplus' author, for a bit before he didn't have time to work on the project further. I've take a different tact now with the reactive system and improved the rendering technique a bit. But he definitely deserves the credit for pioneering the JSX approach 4 years ago now. My initial JSX work was generalizing it for other reactive libraries and then it just grew to this.
Post reply on HN