Live data from Hacker News

Solid – A declarative JavaScript library for building user interfaces

github.com

121–130 of 178 posts

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

#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-renders the whole component chain from producer to consumer, and trying to block useless re-renders with shouldComponentUpdate easily leads to mistakes where children don't update when they should. Since React rendering use lazy evaluation of JSX expressions, tracking who exactly updates and when is much harder than what it might seem initially (akin to tracking mutations in a language with lazy evaluation). As this library actually tracks dependencies and only re-renders what you want, all of this bloat is avoided. One aspect that impresses me in particular is that JSX expressions actually return real DOM nodes, making it easy to keep references to them for imperative operations (not a big deal but so much nicer than React refs).

I'm wondering why you opted for the setState API rather than a nicer imperative API like Mobx. From what I can gather, state changes are tracked by diffing? Why not just return a proxy?

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

#122

Explain the big picture abstraction differences between this and React in two sentences? I don't care about compiler vs interpreter implementation details.

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

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

#123
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

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

#124
post #73
post #55

This (and similar libraries) is the way forward. I joined the Svelte camp a while ago so I'm unlikely to try Solid anytime soon, but had I started with it I wouldn't complain, because the value proposition is the same: an abstraction which is runtime-inexpensive both in terms of CPU usage and bundle size.

I think, the "3rd Age of JS" [1] of frontend libraries are running directly in the browser without a build step. Like in the beginning. ES modules in the browser paves the way. Svelte and Solid are actually the pinnacle of the "2nd age of JS". [1] https://www.swyx.io/writing/js-third-age/

It's an interesting thesis but feels a little cult-ish in mindset. The Neo-isomorphism prediction seems most interesting in terms of the benefits. Because honestly - I think we are MORE likely to see a shift towards containerization of services/apps rather than a module orientation.

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

#125

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 want to think about perf or optimize much.

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

#127

Is it possible to use Solid with just plain JavaScript/TypeScript (like using createElement with React)? I generally find those far more readable than JSX (and is one of the reasons I think SwiftUI and Flutter code looks nicer than React).

It sounds to me that you are looking for Webscript: https://mudgen.github.io/webscript/docs/

Webscript does work with SolidJS nicely.

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

#128
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 almost all reactive implementations in libraries today. I think React has that part just right.

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

#129

Earlier quoted context omitted.

Consider the following pseudo-code: list2 = bubble_sort(list1) render(list2) Now suppose the user deletes one item in list1. The question is now: Will the update trigger a new bubble sort? Will the update do something smarter, like just delete the DOM element?

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?

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

#130
post #120

Earlier quoted context omitted.

It's easier to just open up and debug than say VDOM views since you can see your dynamic expression (what's not updating) and just drop a breakpoint. The template structure flattens so you don't have this issue of nested children and what you are debugging is the actual DOM nodes. It feels more like debugging jQuery. But it is no replacement for good dev tools.

I guess what I meant is that VDOM views (at least pure-functional ones like React) can have a much clearer separation between the view logic and the state logic. I don't have to understand how the VDOM works because it's never entwined with my code that might have a bug in it: I'm just creating a data structure and handing it off. If there's a bug, it's in the creation of that data structure, which is 100% my own cod…

Yes it's all the same thing. Your data is reactive and an be modularized. The renderer is reactive with the DOM basically being a side effect. There basically is no renderer just a reactive system with different types of data. It means there is an incredible amount of flexibility and raw performance.

The tradeoff is rendering isn't particularly special. So the systems consciousness of specific render specific concepts requires additional consideration. There is no "onMount". There are reactive lifecycles but they aren't particularly tied to DOM updates.

Post reply on HN