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?
Solid – A declarative JavaScript library for building user interfaces
51–60 of 178 posts
Re: Solid – A declarative JavaScript library for building user interfaces
#52Can this be used with things like mobx/mobx-state-tree? Absolutely having a blast with MST.
Also, does lack of vdom mean a project like react-native could never really come from this?
Re: Solid – A declarative JavaScript library for building user interfaces
#53Earlier quoted context omitted.
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.
VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?
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.
Re: Solid – A declarative JavaScript library for building user interfaces
#54People loved React because of VirtualDOM. Now JS libraries advertise themselves based having no VirtualDOM. Can someone explain this to me?
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.
Re: Solid – A declarative JavaScript library for building user interfaces
#55This (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.
Re: Solid – A declarative JavaScript library for building user interfaces
#56Earlier quoted context omitted.
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.
So React needs VirtualDOM? Do people want React not to be dependent on VirtualDOM. Is there a reason/benefit?
You might get some answers here, from an SO comment written by virtual-dom’s author: https://stackoverflow.com/questions/21109361/why-is-reacts-c...
The link has been posted in another comment too, here are some chunks that may be relevant to you:
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. Behind the scenes we want to compute a patch operation that updates the DOM to look how we expect. So while the virtual DOM diff/patch algorithm is probably not the optimal solution, it gives us a very nice way to express our applications. We just declare exactly what we want and React/virtual-dom will work out how to make your scene look like this. We don't have to do manual DOM manipulation or get confused about previous DOM state. We don't have to re-render the entire scene either, which could be much less efficient than patching it.
Re: Solid – A declarative JavaScript library for building user interfaces
#57Earlier quoted context omitted.
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...
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.
Re: Solid – A declarative JavaScript library for building user interfaces
#58There is already a project named Solid led by Tim Berners-Lee: https://solid.mit.edu
SOLID was a set of principles for OO design introduced in 2000: https://en.wikipedia.org/wiki/SOLID
In 1983, a database was named SolidDB: https://en.wikipedia.org/wiki/SolidDB
etc. etc.
Re: Solid – A declarative JavaScript library for building user interfaces
#59For the life of me, I can't understand why there is so much emphasis on the virtual-dom and dirty checking. DOM manipulation is expensive, so a check is made to see if it really needs to be done. If you're guaranteed to need an update, then this check is pointless. But this depends on what you're doing. Its really not something that's tied to the technical identity of any library. React, vue, etc, could probably also…
The problem is more in the huge number of renders react does if you don’t do everything perfectly. In a large application it gets steadily slower.
Re: Solid – A declarative JavaScript library for building user interfaces
#60I 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.