2 minutes ago by dustingetz

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

2 hours ago by christophilus

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 like you to push performance forward.

37 minutes ago by orange8

HTML - A declarative markup language for building user interfaces.

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

8 hours ago by hardwaresofton

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

4 hours ago by tarkin2

People loved React because of VirtualDOM.

Now JS libraries advertise themselves based having no VirtualDOM.

Can someone explain this to me?

3 hours ago by cocktailpeanuts

People loved React because it solved a problem. They just happened to solve it using virtual DOM.

but theses next generation frameworks are showing that there's a better way to solve the same problem.

3 hours ago by tarkin2

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

3 hours ago by lukeramsden

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.

3 hours ago by ryansolid

Sort of. I don't think you can write off the virtual Dom. But this is basically my area of research. I'm saying that a specific approach to reactive programming is more performant. I have an article for that too: https://medium.com/better-programming/the-fastest-way-to-ren...

2 hours ago by austincheney

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

2 hours ago by Vinnl

VirtualDOM allows you to roughly code your UI as a function of state. It's never been a magic bullet to better performance, except perhaps compared to Angular.js 1.x's "change detection" methods.

36 minutes ago by lucideer

> 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 but doing so would be much less scalable and require more care from the user of the library.

3 hours ago by curist

VirtualDOM is more of an implementation detail IMO. What I love about React is for its declarative API and we can compose components easily.

3 hours ago by ryansolid

I agree. I love that about React. I think all UI libraries could learn a ton from React.https://medium.com/@ryansolid/what-every-javascript-framewor...

But it isn't something that completely gets abstracted. There is a reason it has been so difficult to make a non-virtual Dom version of React. It isn't impossible, but has yet to fully flesh out despite attempts by a few projects including members of the React team.

3 hours ago by tarkin2

So React needs VirtualDOM? Do people want React not to be dependent on VirtualDOM. Is there a reason/benefit?

2 hours ago by fabiospampinato

React is my UI framework of choice and I don't care one bit about the VirtualDOM or any of its internals for that matter.

I would bet a surprising portion of React's userbase wouldn't even know what the virtual DOM is.

5 hours ago by jarpineh

Good thing this came about. I looked through various JS frameworks for web components a year or so back. I now can't remember did I find Solid had web component support then. I see it has this support now, with Solid Elements. I remember reading Solid articles at the time from Ryan's blog and being impressed. Now it's time to take another look.

Also, I see it's small in size and ES module friendly. Very nice.

5 hours ago by ryansolid

Web Components were what originally led me to keeping the Component side light in Solid, which eventually influenced some of optimizations in that area. I hope you find things have progressed nicely in the last year.

an hour ago by Tade0

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.

2 hours ago by batiste

Really cool, I should have a serious look at this non-virtual dom thing. All the examples make it look like this project is dependable. Sorry for the plug but I somehow explored similar path when creating the Blop language, maybe the author might be curious: https://github.com/batiste/blop-language Maybe I should get rid of the virtual DOM lib. I use?

Daily Digest

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.