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

71–80 of 178 posts

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

#71

Post by kroltan »

orange8 wrote: post #61

HTML - A declarative markup language for building user interfaces. CSS - A declarative, domain-specific language for styling user interfaces.

Neither allow you to build interactive user interfaces besides what is provided by the browser.

I understand the sentiment about reinventing the wheel, but this is more like inventing tyres I suppose (fortunately they are made of rubber, so I can stretch the analogy pretty far, haha). The wheel is there, but there is something to improve to cover more use cases.

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

#72

Post by toastercat »

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.

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

#73

Post by k__ »

Tade0 wrote: 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/

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

#74

Post by EGreg »

olah_1 wrote: post #66
lukeramsden wrote: post #45

Earlier quoted context omitted.

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.

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.

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

#75

Post by nsomaru »

Aeolun wrote: post #57
tarkin2 wrote: post #47

Earlier quoted context omitted.

Thanks. The whirlwind of changing benefits of various frameworks can be rather confusing. I do wonder how much this matters for most apps and at what cost of complexity it brings. But advancements in the field is a obvious good thing.

From my perspective, the things are a bit like this: 1. Make all updates manually with jQuery. This is fast, but hard to keep track of. 2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change. 3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.

If you’re “compiling all possible changes” that’s a diff, right? If there’s no VD, what’s being diffed?

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

#76

Post by cocktailpeanuts »

nsomaru wrote: post #75
Aeolun wrote: post #57

Earlier quoted context omitted.

From my perspective, the things are a bit like this: 1. Make all updates manually with jQuery. This is fast, but hard to keep track of. 2. React, create a virtual DOM, then compare the current DOM with the virtual one, and figure out what needs to change. 3. Solid, Svelte, don’t create a virtual DOM, but have the JS compile all the possible changes so you can make them directly in the DOM like with jQuery.

If you’re “compiling all possible changes” that’s a diff, right? If there’s no VD, what’s being diffed?

the question is not what, but when

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

#77

Post by rich_harris »

olah_1 wrote: post #66
lukeramsden wrote: post #45

Earlier quoted context omitted.

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.

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.

There's no such thing as 'multi-threaded React'. JavaScript runs in a single thread unless you use web workers, which React doesn't (this was a popular idea a few years ago, but people have since come to accept that it adds overhead and complexity out of all proportion to the problem it's designed solve).

You're probably thinking of Concurrent Mode, which the talk does indeed address. Concurrent Mode is, among other things, a clever way of solving one of the problems introduced by the virtual DOM paradigm: that you have to rerun a lot of user code on every state change that will often block the main thread if you don't break it up into chunks.

More on virtual DOM here: https://svelte.dev/blog/virtual-dom-is-pure-overhead

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

#78

Post by ryansolid »

mixedCase wrote: post #68
orange8 wrote: post #61

HTML - A declarative markup language for building user interfaces. CSS - A declarative, domain-specific language for styling user interfaces.

Solid - A declarative JS library for building highly-interactive, logic-driven user interfaces. Better?

Probably. I lifted it from React when I opened sourced the project because I liked how generic it was.

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

#79

Post by amelius »

olah_1 wrote: post #66
lukeramsden wrote: post #45

Earlier quoted context omitted.

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.

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.

Burning cycles in another thread is just as wasteful, and problematic when you run on a battery, or when you run other stuff in the background.

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

#80

Post by ryansolid »

k__ wrote: post #70

"Using JSDOM or similar we can run Solid on the server" Doesn't sound very promising tbh.

I've been working in this area. Solid now has string rendering on the server without DOM emulation. I'm just one person so I went with what was cheapest first.
Post reply on HN