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

101–110 of 178 posts

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

#101

Post by _bxg1 »

ryansolid wrote: post #99
_bxg1 wrote: post #94

Maybe I just need to spend more time studying the material, but I struggle to see how these precompiled frameworks can handle any arbitrary state change one might write into their JS rendering logic. For example: suppose I want to take an arbitrary JSON structure, walk the entire JSON tree, and render it on the page as a tree of nested elements - i.e. a new subtree of divs for each array or object. None of that layou…

At that point you remove the benefit of the compiler but that is fine. You are essentially writing a builder script like VDOM HyperScript. But it isn't like there isn't a runtime portion, it just that it can be smaller due to treeshaking and that the change mechanism is generic (used for everything). I imagine this just falls into the classic Reactive vs VDOM scenario, where VDOM is more performant on creation and re…

That makes sense. Thanks! I do still think this new wave is very exciting and I think it will dramatically improve a lot of cases where people have been (IMO) inappropriately using React thus far. Particularly when it comes to the mess that is hybrid server/client reactive rendering.

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

#102

Post by chrischen »

lucideer wrote: post #62
tarkin2 wrote: post #35

People loved React because of VirtualDOM. Now JS libraries advertise themselves based having no VirtualDOM. Can someone explain this to me?

> People loved React because of VirtualDOM. I don't believe this is true. VirtualDOM is a means to an end for React. People love that "end", but they do not love the means by which it is achieved. Maybe one could argue that people love VirtualDOM because it allowed this "end" to be achieved, but I still think every React fan would much prefer it if was doable without VirtualDOM . It is actually "doable" without vDOM…

I think he may simply be referring to the fact that VirtualDOM/Shadow DOM was one or the “features” React was advertised with initially.

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

#103

Post by hajile »

lukeramsden wrote: post #45
tarkin2 wrote: post #41

Earlier quoted context omitted.

VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?

This is a good talk on the matter from the creator of Svelte himself, if you're interested: https://www.youtube.com/watch?v=AdNJ3fydeao Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.

I haven't seen proof that the output of these libraries is restricted in any meaningful way. Is there a case where some small input n yields !n code? Is there even any proof that all states can actually be tracked? In the case of a vDom, your code size is fixed and execution has a provable upper-bound.

Even if that could be proven, code bloat is still a problem. With a vDom library, the render engine size is fixed. Moreover, those functions are guaranteed to run enough that they will be optimized by the JIT while changing render functions for every component could mean your renders are optimized for this view, but back in interpreter land when rendering the next view.

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

#104

Post by lhorie »

ryansolid wrote: post #93
toastercat wrote: post #72

The negativity in this comments section is astounding. Personally, I was originally introduced to it by someone in the Mithril.js gitter chat, and think it's a great project. I wish the Solid team the best and look forward to trying out Solid in my next toy project. The performance benchmarks and relatively clean API are truly impressive.

Thank you for your kind words. It can a difference to have the kind words of a few strangers. I'm used to these sort of responses now. And welcome it to a certain degree. Insightful comment can lead to interesting discussion. Ignorant ones gives me a platform to educate. But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback"…

Disclaimer: I'm that Leo ^ :)

Unfortunately, JS fatigue is real and it can be challenging for someone who has their hands full with just relearning new React idioms to also evaluate the dozens of other libraries out there, so it's easy to miss a gold nugget.

For those who are not seeing the value proposition here, think Svelte, but where the "reactivity magic" is encapsulated via Components to still allow React-like "it's-just-JS" component code, while also getting rid of a lot of runtime overhead and the complexities associated with trying to optimize a virtual dom (as has been the recent direction for React).

One great benefit over Svelte with this approach is that you can use Typescript in templates (something that Svelte still is not able to do).

Solid's performance claims to fame are also legit (i.e. it doesn't sacrifice good devexp, good engineering, unlike many of the top performers in the stephen krause's benchmarks).

The only thing I wish was better is docs. It starts off "spilling its guts", so to speak, and while that is an ok way to explain why Solid is different than others and to garner interest from library authors, it's also not super beginner friendly. One cannot, for example, easily find docs for `` even though it's analogous to core syntax if we were to compare to a programming language. Putting a follow-along tutorial upfront would go a long way.

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

#105

Post by ryansolid »

_bxg1 wrote: post #95
broadwall wrote: post #84

Is there dedicated DevTools support for Solid like there is for React, Vue, Svelte, and co.? If not, is there a convenient way to inspect state, props, and the component hierarchy?

I actually think this is extremely important. One downside of these compilation-driven frameworks is that they would, I assume, make it much more difficult to track with exactly how your code manifests at runtime, and would therefore make it harder to debug. Even setting that aside, I'm a strong believer that "frameworks" (contrasted with "libraries") have a responsibility to bring their own tooling, because existing…

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.

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

#106

Post by ryansolid »

quantummkv wrote: post #60

I am digging this. The main issue I personally have with svelte is that it goes into a completely different API design than React. The closeness with the React design makes it better than svelte imo.

Thanks. I get criticism like "Why even make this? just use React." But it's so different. Yet I didn't want to throw everything away. People forget React came up when there were tons of libraries with similar reactive approaches and won our hearts and minds. It does a lot of things purposefully and it does those things well. We need to learn from the past it we are doomed to repeat it.

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

#107

Post by ryansolid »

lhorie wrote: post #104
ryansolid wrote: post #93

Earlier quoted context omitted.

Thank you for your kind words. It can a difference to have the kind words of a few strangers. I'm used to these sort of responses now. And welcome it to a certain degree. Insightful comment can lead to interesting discussion. Ignorant ones gives me a platform to educate. But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback"…

Disclaimer: I'm that Leo ^ :) Unfortunately, JS fatigue is real and it can be challenging for someone who has their hands full with just relearning new React idioms to also evaluate the dozens of other libraries out there, so it's easy to miss a gold nugget. For those who are not seeing the value proposition here, think Svelte, but where the "reactivity magic" is encapsulated via Components to still allow React-like…

Thank you as always. Early days spent so much time justifying things, everything became these expositions. Time to tighten up.

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

#108

Post by amelius »

have_faith wrote: post #98
_bxg1 wrote: post #94

Maybe I just need to spend more time studying the material, but I struggle to see how these precompiled frameworks can handle any arbitrary state change one might write into their JS rendering logic. For example: suppose I want to take an arbitrary JSON structure, walk the entire JSON tree, and render it on the page as a tree of nested elements - i.e. a new subtree of divs for each array or object. None of that layou…

It's my understanding that regardless of the complexity of your custom JSON data at some point while parsing the tree you have a line that says "if obj is of this type, then render this component for this node", all Svelte/Solid etc need to know is that this is the line where a Component is being assigned to a variable that is going to be rendered in the template. Or are you saying you want a layout rendered from JSO…

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?

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

#109

Post by hajile »

ludami wrote: post #81
cocktailpeanuts wrote: post #76

Earlier quoted context omitted.

the question is not what, but when

Exactly. Think of is as the classic compiled vs. interpreted languages debated. One is clearly faster than the other but the slower one may have different advantages.

Ahead-of-time vs Just-in-time is a more accurate description.

In this case, there's no evidence that precompiling is faster in theory -- let alone in practice. In the JS framework benchmark suite, SolidJS and InfernoJS performance is almost identical (with SolidJS having a much larger margin for error in most tests).

This is the BEST possible case for precompiling too. In the real world, JITs take a long time to warm up (a couple hundred executions before all the optimizations kick in). With the vDom, you warm up ONE set of code that then runs forever. With the precompile, it has to warm up for EVERY new component and potentially slightly different codepaths within the same component.

The JS framework benchmark reuses the same components for everything which is a huge advantage to precompiled frameworks while not having much impact on vDom ones (as the actual components in both cases usually won't optimize very much due to being polymorphic).

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

#110

Post by [deleted] »

austincheney wrote: post #49
tarkin2 wrote: post #41

Earlier quoted context omitted.

VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?

Perhaps faster than other framework implementations but there is no way it’s faster than the standard DOM methods. https://stackoverflow.com/questions/21109361/why-is-reacts-c...

[deleted]
Post reply on HN