3 ms·

Disclaimer: virtual dom library author here One does not simply "compile to the standard DOM" to get performance gains. A virtual dom is a binding abstraction,

• austincheney 7y ago
  > If you want to compile away the virtual DOM, then the compiler has to be aware of how data changes propagate through your model That makes the assumption that a virtual DOM is needed for efficiency because the model exposed by a framework instance would be doing extra work otherwise. That is a red herring for two reasons: 1. You don't need any framework, whether MVC or otherwise, to have a fully expressive application written in JavaScript. If there is no framework and no model there is nothing superficial to be aware of or propagate through. Perhaps the vDOM provides performance improvements compared with other framework techniques. The compiler doesn't need to be smart when unnecessarily complex considerations are taken off the table. 2. There are only two classes of APIs exposed by the browser to JavaScript: The Web APIs and the DOM. Regardless of how clever or organized any framework is it still ultimately interacts with the page using the same basic set of instructions as everything else. For example a JavaScript framework isn't exposing new access points to hardware, memory, or markup artifacts that aren't already available as web standards. The performance benefit of bypassing a virtual DOM is simply due to executing fewer instructions, which means not executing a giant framework in addition to bypassing its virtual DOM. As an analogy I don't need to blow up a dam and change the course of a river to put out a camp fire, but if I were going to put out a campfire by diverting a river I now have many additional performance factors to consider.
  • lhorie 7y ago
    It sounds like you're getting caught up on the loadedness of the term "MVC". Model means anything that is conceptually related to data. You don't need a framework to have a model. If you have a vanilla js app and call fetch and assign to a variable, that's your model. Unless you carefully write procedural code by hand to mutate specific DOM targets based on a relevant state change, the abstraction (be it a vdom or a compiler) will have to do it for you. What view frameworks/libraries do is expose interfaces for a developer and turn code written against those interfaces into execution plans. The abstraction trend-du-jour is to have declarative style have reactive semantics (i.e. `foo = 1` triggers a change to any views that read `foo`). The challenge is if you have N state values and M DOM bindings, how do you efficiently translate changes to a subset of state values to a subset of DOM calls for only the bindings that are affected. Something has to do this determination. Either a vdom, a dirty checker, a KVO, a compiler or you. > If there is no framework and no model Yeah, of course you can write raw DOM calls manually. But people don't want to, citing maintainability concerns or whatever. VDOMs, dirty checkers and KVOs have already been explored and have known trade-offs. What I'm saying is that compilers leveraging today's state-of-art will necessarily compile to one of those techniques, because there's no implementation that does reactivity analysis at compile time. > I don't need to blow up a dam and change the course of a river to put out a camp fire To borrow your analogy, you don't need to change the course of a river to put out a camp fire, but if you want to build a system to put out fires in a city, you'll most likely use a plumbing system to divert water from your local water sources, because manually bringing buckets of water from the river will usually not cut it, and water teleportation hasn't been invented yet.