Create our own virtual DOM...

[jnbdz]

(1) define a standard way to express a VDOM as a JSON, maybe JSONML or, better, something like
We've used jsonml before ( https://github.com/Raynos/jsonml-stringify ). It kind of works but is a pain to write.
We now use vtree/vnode.js ( https://github.com/Matt-Esch/vtree/blob/master/vnode.js ) which is a data structure
VNode : { tagName: String, properties: Object<String, Any>, children: Array, namespace: String }
However do not be confused with the extra pre-computed properties on the vtree/vnode.js implementation, those are performance related implementation details.
and then implement a function toHTML(VDOM) -> HTML
https://github.com/alexmingoia/virtual-dom-stringify
(2) define a standard way to attach / detach event handlers to the DOM (let's call it an Events object).
This is a non trivial problem.
(3) define a standard way to express a patch to the DOM: diff(vdom1, vdom2) -> Patch and implement a function patch(domNode, mypatch) -> side effect on the DOM
diff(tree, tree) -> VPatch https://github.com/Matt-Esch/vtree/blob/master/diff.js
VPatch https://github.com/Matt-Esch/vtree/blob/master/vpatch.js
patch https://github.com/Matt-Esch/vdom/blob/master/patch.js
Note that patch is not enough, you also need a way to "create" an element from a tree for initial rendering, doing a diff with an empty vnode and a complex tree and applying lots of patches is a bad work around.
create(vtree) -> DOM node https://github.com/Matt-Esch/vdom/blob/master/create-element.js
with standard specs, we'll have competitor implementations (good thing) but not fragmentation and lock-in (bad thing) in the new VDOM trend
Last time i spoke with the author of mithril his opinion was:
I don't think either project would be interested in breaking its APIs to conform with the other either, and personally I don't care for API standardization bureaucracy a la Promises/A+.
VDOMs would be a standard protocol: a view is any pure function that outputs a VDOM, decoupled by frameworks
re-usable views is as functions that return VDOMs only works for stateless views. Most views are not stateless. once you have stateful views the coupling to a framework starts to come into play.
high testability: being a JSON structure a VDOM is easily traversable and assertable with simple tools like assert.deepEqual
https://github.com/parshap/vtree-select
https://github.com/StephanHoyer/mithril-query
a component would be a pure function that returns the pair [VDOM, Events].
Unless you define what Events means this won't compose well.
Being able to do return h('div', [ myComponent(...) ]) is important. Unpacking tuples all the time gets tedious incredibly quickly, not to mention that a pure view function doesn't know what to do with events other then return it.
This needs to be thought through more.
with the pair [VDOM, Events] it should be straightforward to implement server side rendering on first access and then hydrate your SPA app on the client
I talked about how server side rendering works ( Raynos/mercury#55 (comment) ). Note that hydration is non trivial.

Source:

https://www.reddit.com/r/javascript/comments/2jav2q/is_there_any_good_standalone_implementation_of/
http://elm-lang.org/blog/blazing-fast-html