Hacker News Reader

Comment by manishsharan | Hacker News Reader

I have been using Backbone + moustache/handlebar templates and I am not clear on why use a virtualDOM. My application has several views and in my views, I use events to sync data model changes with the view and the view's render function maintains the DOM element . None of my views have to deal with the whole DOM. Therefore, I am really confused. So with my apologies for asking a dumb question : why maintain the whole virtual DOM? And what am I missing with Backbone + mustache based approach ?

View on HN

Say you want a form with as-you-type validation. You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you.

I find Backbone events extremely hard to work with (error-prone, super hard to test / debug), because there are many operations that emit tons of events. So you either listen+render() on any event (very inconsistent performance if your app has any kind of complexity), or you hand-pick the events you want to react to (event-hell). Using immutable objects along with React's PureRenderMixin means you can just render() on any change, with great performance. It makes your UI purely functional, very easy to reason about, and easy to test.

> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you.

This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" when that's just not the case.

We're talking about Backbone + templating here, and that is what happens with those libs.

Obviously there are other libs / frameworks that can do that, all of them using some sort of shadow DOM.

You've got that backwards. Every other framework "only renders what has changed". React re-renders everything.

Reread that in the context of the parent's statement. There is a misconception that every other template library blows away parts of the dom on each update and that only React will do something like input.value=newValue, but this is not the case.

I sure don't see where that misconception is the fault of "the React community."

In fact, this comment is the first time I've seen that formulated. I'll be honest, I don't read every React-related forum entry on the Internet, so I may have missed someone somewhere spreading such a misconception, but there certainly is no such centrally communicated premise.

React only "renders" everything within its shadow DOM. It then applies the results of diffing the previous and current version trying to use the most atomic operation (innerText, add/removeClass, add/removeNode, etc)

Thanks. I get it now!

At Floobits, we started out using Backbone and handlebars because that is what we knew. About a year ago, we did a rewrite into React + Flux (our own implementation, because it was a year ago). The rewrite reduced KLOCs by something like 40%. Moreover, it radically simplified the code base. The big wins include one way data binding, updating views reactively, and removing boilerplate.

I did not realize it at the time, but two way data binding is evil. We spent a disproportionately large amount of time tracing (hard) bugs related to dispatching events. Bugs related to a child updating its parent that may or may not update the child again. Data should flow in one and only one direction. It may be possible to do this in Backbone, but its not encouraged when listening to models.

With any View system for the front end, you are necessarily responsible for creating the initial state of the DOM. You are also typically responsible for updating the DOM with your application state. If you ever run into a performance bottleneck, you will be forced to step out of your template system - you will either have to decompose your templates into needlessly small atomic chunks or resort to ad hoc DOM munging. Either solution is awful. React more or less lets you specify how to turn data in DOM in exactly one place for all time. In other words, if you care about performance, you will end up poorly reimplementing one of the best features of React.

And finally, Backbone has to be the most verbose JS framework I've ever used.

VirtualDOM shines when your document tree has a dynamic structure. If you never add or remove DOM nodes and just alter text contents or CSS classes then its easy to keep references to the internal nodes that need to be updated and to write "onchange" events to keep things up to date. However, if your document is more dynamic you can't keep references to the internal nodes anymore so it gets harder to write observables but its just as easy as the static case if you use virtualdom.

Thank you. This is the distinction I was looking for

Events firing en listenTo'ing all over the place makes it really hard to reason about what will happen to your UI when state changes. The bigger the project (or the more complex the UI), the harder it is to keep track of all the events and their side effects.

Reply on news.ycombinator.com