
Rolling a virtual DOM - codr4life
https://github.com/codr4life/vicsydev/blob/master/virtual_dom.md
======
bastawhiz
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.

~~~
codr4life
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
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.

~~~
codr4life
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.

~~~
alnitak
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.

~~~
codr4life
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.

~~~
LoSboccacc
Foundations for a house isn't a house

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

~~~
codr4life
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.

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

~~~
zodiac
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.

~~~
codr4life
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.

~~~
zodiac
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"?

~~~
codr4life
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.

~~~
zodiac
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?

