search

google / incremental-dom

An in-place DOM diffing library
http://google.github.io/incremental-dom/
Apache License 2.0
3.53k stars 178 forks source link

Project status / how it compares? #315

Open c-dante opened 7 years ago

c-dante commented 7 years ago

So I stumbled on incremental-dom over the last month or so, and I was very surprised that I had not heard of it until now.

To cut to the chase, this blog post was a motivating example to compare how different DOM rendering libraries compare. I decided to implement the same test using the incremental-dom here.

The visual performance of the incremental dom easily rivals and surpasses that of the inferno js implementation. I've been VERY impressed with the incremental-dom API, and feel that any code that uses the "elementOpen/Close, text, elementVoid" API is the right direction to go for DOM manipulation, and I'm wondering where this library is going and I'm voicing concern that the verbose half of the JS community has been neglected this gem.

RNCTX commented 7 years ago

I am in the same boat you are in. I just stumbled across this and am wondering why it's not everywhere.

Of course we can look at existing models of web development and say why, based on the most common means of development in use at the moment. That current model does not encourage anyone to consider anything beyond browser compatibility, and surely not performance because the performance of most (all?) of the choices out there is not good.

sparhami commented 7 years ago

I'm wondering where this library is going and I'm voicing concern that the verbose half of the JS community has been neglected this gem.

The original goal was to provide a low level API for other libraries to build on top of. There has been interest in a higher level API that is more developer friendly, so that is something that I'm exploring currently.

I am in the same boat you are in. I just stumbled across this and am wondering why it's not everywhere.

Other libraries do other things well, so I think it depends on what trade-offs you want to make.

That current model does not encourage anyone to consider anything beyond browser compatibility, and surely not performance because the performance of most (all?) of the choices out there is not good.

In a lot of cases, the performance may be good enough and browsers are always working to make the things developers are doing much better. For example, V8 is coming out with a new garbage collector that should libraries that build up virtual DOM trees.

RNCTX commented 7 years ago

I think people follow Google/Facebook/Twitter without considering why ;).

If you have billions of users you have a definite interest in browser-side processing. If you are not serving billions of users, other things can make a lot more sense.

dy commented 4 years ago

Just stumbled across this, after struggling with snabbdom, nanomorph, virtual-dom, (not mentioning react), morphdom, vidom. Seems very attractive and reasonable implementation, giving it a spin.