There are a number of performance advantages to a virtual DOM. That's why React uses a virtual DOM - unless you're also thoroughly convinced you know more than Facebook's engineers. Google the subject a little.
But there aren't, there are performance advantages to reusing Nodes due to the specific way that browsers implement render reflow. If those implementations ever change, or you use React on a browser that doesn't suffer from implementation specific perf issues, you've introduced unnecessary complexity.
This is the type of rhetoric that is repeated without personal knowledge of internals or without understanding why the issue exists to begin with. You're basically saying that tree-based structures are inherently expensive.
Read implementing a browser a little. Read specs a little.
Snabbdom is a gem of a library, it makes microsoft ( angular) and facebook ( react ) look like idiots.
Whoever came up with dom diffing in Facebook is clever, but facebook took that idea and made it into a weird beast, which doesn't integrate well with the rest of the open web ecosystem ( I guess facebook has way too many downstream engineers )
Snabbdom implements the core dom-diffing algorithm and leave the architecturing to you and that is where its power lies.
Snabbdom is really powerful when you mix it with the rest of the small libraries that are written in the UNIX way.
I'm kinda out of the loop with Javascript nowdays, but how would one react to changing data on some input element and receive it in Javascript, integrating elegantly with this library?
There's an event module built into snabbdom, so you can add a handler for `input` events, change whatever state you want, then create a new vnode and patch the dom. The architecture is very much up to you, snabbdom just updates the dom.
This, like React, is an inferior reimplementation D3. Whereas React is both slower, less expressive, and less compositional, Snabbdom seems to have settled for just being less expressive and less compositional.
I really like this library. I've used it to implement a minimal React+Redux toy "framework" when I was spending hours in cranky trains in India.
It turns out in 200 lines of TypeScript I can have a view library which has everything I like from React/Redux/mithril/Elm:
* reactive (hopefully fast, I haven't benchmark anything but I trust snabbdom benchmarks)
* simple API (basically 2 functions) and simple workflow (event -> update -> render)
* hot-reloadable (thanks to Webpack HMR)
* time-travelable (inspirated by Elm Reactor)
* type safe-ish (I wish I could do more here but I think TS is limiting it - a const keyword would be awesome)
Disclaimer: I wrote that during my Asia backpacking so the code is ugly and not even named consistenly but as I'm looking for a job I will try to make it more presentable/usable soon. https://github.com/maattdd/AuberJS for those interested
Random interesting bits:
function draw() {
if (m && node) {
const new_node = ballastView(r,m)
patch(node,new_node)
node = new_node
} else {
console.error("Unable to draw")
}
}
The readme explicitly mentions https://github.com/yelouafi/snabbdom-jsx which allows the use of JSX syntax. While there are trade offs with choosing any virtual DOM library, syntax is not a limiting factor for this one.
24 comments
[ 17.9 ms ] story [ 873 ms ] threadThis is the type of rhetoric that is repeated without personal knowledge of internals or without understanding why the issue exists to begin with. You're basically saying that tree-based structures are inherently expensive.
Read implementing a browser a little. Read specs a little.
Snabbdom is a gem of a library, it makes microsoft ( angular) and facebook ( react ) look like idiots.
Whoever came up with dom diffing in Facebook is clever, but facebook took that idea and made it into a weird beast, which doesn't integrate well with the rest of the open web ecosystem ( I guess facebook has way too many downstream engineers )
Snabbdom implements the core dom-diffing algorithm and leave the architecturing to you and that is where its power lies.
Snabbdom is really powerful when you mix it with the rest of the small libraries that are written in the UNIX way.
you attach event-handlers to each virtual-dom the same way you would do with a normal-dom.
and those event-handlers can react to change the way you want.
If you mean how to do auto-data binding
oldDom = patch (document.body,newDom)
newDom = h ('div','hello world')
patch (oldDom,newDom)
patch is the function that does the dom diffing.
The amazing thing is most web components do not need auto-diffing.
Sometimes you want fine grained control where you write your own update functions - making imperative changes to the dom based on your needs.
And for other web components where you want more auto-updates you can patch accordingly.
The thing that is amazing is that you can dial it up and down based on your individual needs.
A good example is table components with a lot of data.
You really do not want to incrementally update the table.
So for the divs with the data you patch
but other components that have a lot of interactivity you can simply not patch and do updates by hand.
What is the standard way of doing this in D3?
It turns out in 200 lines of TypeScript I can have a view library which has everything I like from React/Redux/mithril/Elm:
* reactive (hopefully fast, I haven't benchmark anything but I trust snabbdom benchmarks)
* simple API (basically 2 functions) and simple workflow (event -> update -> render)
* hot-reloadable (thanks to Webpack HMR)
* time-travelable (inspirated by Elm Reactor)
* type safe-ish (I wish I could do more here but I think TS is limiting it - a const keyword would be awesome)
Disclaimer: I wrote that during my Asia backpacking so the code is ugly and not even named consistenly but as I'm looking for a job I will try to make it more presentable/usable soon. https://github.com/maattdd/AuberJS for those interested
Random interesting bits:
I want to copy my html snippet and only chance the dynamic bits.
There should be portability from other frameworks.
React's API Base is small. If we think react is slow, then there should be a lighter more performant version offering a descent migration path.