
Morphdom – fast and lightweight DOM diffing/patching (without the virtual part) - psteeleidem
https://github.com/patrick-steele-idem/morphdom/
======
explorigin
I'd take it with a grain of salt.

    
    
      - Benchmarks are only for Safari and without good documentation for how they 
        were performed.  Measurements are only in the 100ths of seconds where these 
        measurements should have much more granularity.
      - The TodoMVC (arguably the most real-world) benchmark is nearly 50% slower 
        than virtual-DOM.
      - virtual-DOM is fairly mature at this point where as MorphDOM looks very 
        young.
      - virtual DOM implementations allow you to do things like React Native

~~~
striking
Noted. Meanwhile, this is 12.3kB (uncompressed) while React's core (minus
addons or anything) is 121.7kB. For something as young as this, and to do
fairly well in a number of benchmarks compared to the highly engineered piece
of work that is React is pretty great.

This library can only get better. It's great to see someone trying to make a
more lightweight React.

Also, you can see exactly how the benchmarks are run through the /test folder.
My test using PhantomJS gave me the same results as the recorded statistics
against Safari. And because it uses the browser's built in DOM toolkit rather
than a virtual one, (in theory) it should become faster whenever browser DOMs
become faster.

~~~
psteeleidem
On the following note:

> it should become faster whenever browser DOMs become faster

The killer feature of React is that it made it possible to efficiently
rerender the entire UI and for developers to _not_ have to write code to
manually manipulate the DOM. I hope browser vendors take note of this and do
more to support this use case. Ideally, morphdom should not even exist and we
could instead have the browser natively do the job of diffing/patching the
DOM. Admittedly, there would have to be a lot of details to work out, but
React, virtual-dom and morphdom are working in the right direction. Behind the
scenes, the implementation might change and any good UI framework should make
this a non-breaking change.

------
gobengo
This sounds very similar to [http://google.github.io/incremental-
dom/#about](http://google.github.io/incremental-dom/#about) (esp skipping the
virtual part).

Can anyone point out any notable differences?

~~~
psteeleidem
Here's the notable differences based on my understanding after looking over
the docs and the source code:

\- morphdom does diffing between two real DOM trees while incremental-dom does
diffing between virtual DOM nodes and real DOM nodes \- incremental-dom is
only meant to be used with templates that compile to use incremental-dom
(won't work with templates that render to HTML strings) \- morphdom can be
used with any templating engine that produces an HTML string (or real DOM
nodes) \- With additional improvements, morphdom could be used to do diffing
between a real DOM tree and a virtual DOM tree as long as the virtual DOM
nodes are upgraded to real DOM nodes if they need to be added to the final
real DOM. In addition, the virtual DOM nodes would need to have an API that
overlaps with the API of real DOM nodes.

Also, it appears that incremental-dom doesn't reuse DOM nodes that move to a
new parent, but I could be mistaken. Hopefully someone more familiar with
incremental-dom will chime in.

------
tracker1
The virtual dom solutions can run outside, without a _full_ DOM
implementation, which are very slow and resource intensive on a server. Which
is needed for client+server-side rendering options.

~~~
psteeleidem
You don't need a virtual DOM or real DOM on the server to render HTML. The
fastest way to render pages on the server is to compile templates into
JavaScript programs that produce an HTML string (not virutal DOM nodes and
definitely not real DOM nodes) and you can use almost any HTML templating
engine to do client+server side rendering. morphdom is only meant for use in
the browser when you need to update the DOM based on new HTML/DOM nodes.

~~~
tracker1
True... but React offers a lot in terms of client-side components, and being
able to re-use components outweighs having to use a lesser templating system
and/or having to manage two rendering paths for each component. Beyond that,
virtual DOM nodes aren't too different from an abstraction of rendering
against a compiled template.

------
pags
Currently using virtual-dom to power my front-end system, but have been
waiting for something like this. Can't wait to see how it works in comparison.

------
saurik
[https://news.ycombinator.com/item?id=10063565](https://news.ycombinator.com/item?id=10063565)

~~~
psteeleidem
For the record, I got an email from Hacker News asking me to repost it since
they thought it was a good story and it did not get many views. It's not wise
to post something to Hacker News late on a Friday :)

~~~
saurik
I refrained from providing commentary on whether or not posting it a second
time is "good" or "bad". While small, there was commentary on the previous
link, and that commentary might be valuable to people. I personally think that
Hacker News should have an integrated feature that shows "previous
discussions" of every posted link. FWIW, reddit has that feature, and it is
extremely valuable. (I provide this extra context, as someone down voted my
attempt to be useful in addition to you providing a semi-defensive response.)

