5 ms·
Well, the web browser only understands strings so sooner or later that will have to happen. But before and in-between generating strings you're free to update t
by codr4life 10y ago
Well, the web browser only understands strings so sooner or later that will have to happen. But before and in-between generating strings you're free to update the DOM, which is the the exact purpose of keeping it around. And like I mentioned in the post, this is a general purpose foundation on top of which change tracking will be added as an opt-in feature.
- mikekchar 10y agoI think the mismatch here is that you are not implementing a DOM in the way that most people refer to a DOM. Technically it is a "Document Object Model", so personally I don't think you are "wrong" per se, but it is confusing. Most of the time when people talk about a DOM, they are talking about traversal and updating of a tree that represents an HTML document. Specifically when people are talking about a "virtual DOM", they are talking about building a parallel representation of the browser's DOM with nicer traversal and update methods. You then need an efficient update mechanism between the "virtual DOM" and the "real DOM". Code that gives you a handy way to generate HTML programmatically is very useful and I've written similar things myself many times. I don't think you'll get much traction calling it a "virtual DOM", though, even though it implements a Document Object Model.
- codr4life 10y agoWhat would be the point of implementing the same thing the same way that has already been done a thousand times by others? It's a DOM, and it's virtual; hence a virtual DOM, period. Like I mentioned in the post, this is a foundation on which change-tracking and callbacks will be added as opt-in features.
- deleted 10y ago[deleted]
- alnitak 10y agoVirtual DOMs are typically used to reduce the number of operations needed to update the real DOM. In order to achieve that, a virtual DOM is typically used to diff the previous and the next state of the DOM (before and after the data changes), and based on this diff calculate the shortest amount of steps to modify the real DOM to represent the new data. While any DOM that doesn't render its tree can be considered a virtual DOM semantically speaking, the idiomatic usage of it so far is not achieved by this current work. It is only confusing to the reader, who might have seen this term used in other popular projects. I see this more as a DOM builder, similar to JSX for example.
- codr4life 10y agoWhich part of 'this is a foundation on which change-tracking and callbacks will be added as opt-in features' didn't you understand? It's a DOM and it's virtual, hence a virtual DOM.
- LoSboccacc 10y agoFoundations for a house isn't a house
- millstone 10y agoA DOM refers to the programmatic interface (the Object Model), as distinct from the web browser's textual (Text Markup) interface. If the difference isn't clear, consider pre-JavaScript browsers: they rendered HTML with no DOM at all. This project goes through the text interface, so "virtual HTML" might be more apt than "virtual DOM."
- mikekchar 10y agoProbably I should have kept out of the discussion. Sounds like you are having a hard time of it. Whatever you call it, it looks interesting and I'll be very curious to see how you tackle the opt-in features.
- bastawhiz 10y agoUntrue. The browser allows you to construct the "real" DOM using an API. The difference is that you can update only the parts of the page that require updating, rather than creating new HTML and forcing it to be reparsed (and refreshing the entire page) on every state update. Try, for instance, to rerender the DOM in the way your code does when you have event listeners. If you're creating new markup each time, you blow away your listeners on the whole page.