Rolling a virtual DOM | Hacker News Reader

Rolling a virtual DOM

github.com

43 pointscodr4life24 comments

This isn't really a "virtual DOM" in any way, though. It only generates strings, which defeats the whole purpose of keeping a separate DOM around.

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.

I 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.

What 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.

Virtual 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.

Which 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.

Foundations for a house isn't a house

A 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."

Probably 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.

Untrue. 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.

It would be more interesting if the code was tied with parenscript instead of generating the raw HTML directly. That way you could generate the Javascript needed to manipulate the real DOM. Otherwise, this isn't a virtual DOM, it's only a minimal template engine.

We'll see when I get to the change-tracking part, last time I checked out parenscript it still didn't rub off on me. I would strongly recommend generating straight HTML for the initial layout though, I have really bad experiences from debugging completely dynamic pages in the browser. Additionally, one of the aims of this library is to generate any kind of HML in a reasonably effective way, whether static or dynamic. Still, a virtual DOM is exactly what it is; a template engine would just dump the strings without offering support for modifying the document.

Keep on downvoting, friends; as long as it makes you feel better :)

Look, I'm sorry if I stepped on any ego toes; but I truly think most of the current practice is a mess of bad ideas and duct tape, and I have plenty of experience to back that up. Disagreeing is one thing, shooting messengers at any cost is counter-productive. I'm sharing ideas, you're arguing definitions.

I don't care about voting, but it's understandable: This is but a templating library written in non self explanatory Lisp with a bizarre rollback feature.

And from another, more constructive perspective it's the beginnings of a modular, extensible virtual DOM implementation in perfectly acceptable Common Lisp with transaction support. Is this the way you look at the world in general, with -10 negative bias? Or did I hurt you ego somehow?

I did not cast a vote, I merely tried to explain the reasons others might have had for downvoting, since it obviously upset you and you seemingly didn't understand why others downvoted.

Trust me, I'm more amused at the level of ego scrambling than upset about anything. My goal is to make sure the ideas reach out through the noise of ignorance; and they are, despite all the huffing and puffing in this thread.

You make it pretty clear the ego being hurt doesn't belong to any of the commenters.

Nothing could be further from the truth, my only beef is that nothing of substance has been said; anyone with eyes to see would tell you the same. The fact that you feel the need to push the useless bullshit further tells a story of sore toes and little else.

The definitions are important. I agree with your message (your thing is better than say rails templating) but virtual DOM basically means "react-style virtual DOM, implemented in client side JavaScript, with fast diff support, used to infer updates" now, instead of your definition of it.

When did React become the definition of anything? Why not Seaside? They came up with the idea around 15 years before React entered the scene. This is pure stupid, straight through. It's a DOM and it's virtual, hence a virtual DOM.

No it's not stupid - your etymology makes much less sense to me. DOM in virtual DOM refers to the tree that browsers use internally and provide an API against, not just any tree like structure that can be serialized to HTML (which seems to be your definition). That's why it's referred to as "the DOM" with a definite article. The "virtual" part then means something like "shadow" as in a copy that is kept in sync. By that definition you didn't create a "virtual DOM". What is your definition of "virtual", "DOM" and "virtual DOM"?

Feel free to define whatever however you want. This is a virtual DOM, because that is what the expression means; who's most popular right now matters not at all. And the only reason you feel obliged to drag the discussion down to this level is because it makes you feel insecure. You would do well to learn to like that feeling instead, that leads forward.

Well, I'm asking you to tell me why you think your thing is a "virtual DOM". And your only response on this thread is "this is a virtual DOM, because that is what the expression means". Why is it what the expression means?

Reply on news.ycombinator.com