DOM ViewModel - A thin, fast, dependency-free vdom view layer

• views will no longer be auto-keyed by the passed-in model. it's too surprising and i've had to explain it too many times. explicitly keying by the model when needed isnt all that difficult.
• domvm.lazyList() creator & domvm.LAZY_LIST flag for creating deferred homogenous children that can reuse old vnodes without additional allocation.
• render() will be able to return vm.node (the old vnode) to prevent/optimize redraw when no changes.
• xlink:href support in svg
• vm.diff() & vm.hook() will be removed in favor of what is already possible:
  • ~~direct assignment vm.hooks = {}~~
  • new: vm.config({hooks:..., diff...})
  • object return {hooks: ..., diff:..., render: ...}
  • externally passing in through opts: {hooks: ..., diff: ...}
• dist builds may be split into a separate branch, since merging and rebasing are currently a nightmare and always result in conflicts.

v3 should be ready within the next couple weeks.

Opening a new issue only to get this on the radar; I am not able to prioritize this for the next two weeks as the CEO is in town an I am demoing the proof-of-concept and will be in strategic meetings. However, I will definitely come back to this...

On another (only tangentially related) thread I said:

I do have to say, for my mildly complex view of a few thousand nodes there is noticeable lag that, so far, I can only attribute to view generation and downstream. But I haven't looked into it deeply since function is a much higher priority to me.

It turns out that when I dumped and formatted the HTML my "few thousand" is closer to 8K. I have all the major details of my UI in place, now.

I am seeing a rendering time of about 500ms to render. And about 700 ms in paint. This is on Firefox 47 and may be directly related to that. Chrome seems quite spritely by comparison, though still not quite as snappy as I'd hoped. The total is about a second of latency.

I'll report back here as I make progress. The reformatted HTML is attached if you are curious. Please understand that this is still just a prototype.

Screen-80x24.txt

Also for the curious, the perf graph:

The 1.x view module's codebase is getting increasingly harder to reason about and properly optimize. Rather than trying to fight perf death by 1,000 papercuts, I've decided to test a clean-slate rewrite to see what can be learned.

The current codebase does a lot of type-checking and value testing to process the JSONML templates (often in multiple places and several preprocessing passes). In addition there is the non-congruence in the template structure because everything must be in array-style declarative form. On top of that there is value coercion and other "helpful" features that are rarely used but always degrade perfomance even when they arent.

What I've done with the rewrite is to start with a hyperscript API & explicit child arrays that delegates some of the type-checking to the user and generates vnodes directly, reducing many allocations and preproc code. In addition, I've added a fluent API that can be used to set special vnode properties directly rather than forcing object allocation (though both will still be supported with different speed implications):

// 1.x
[".test", {_key: "abc"}, "hello world"];

// 2.x
h(".test", {_key: "abc"}, "hello world");     // faster than 1.x
h(".test").key("abc").body("hello world");    // fastest

// 2.x child arrays must be explicit
h(".test", [...]);
h(".test", {_ref: "myNode"}, [...]);
h(".test").ref("myNode").body([...]);

In addition to a much leaner/cleaner codebase, the performance of 2.x is significantly better than 1.x. While it's still early and most features have not been ported. One of the things that 2.x excels at is "doing nothing". The current 1.x branch has 3.9ms overhead at 0% mutation while 2.x is 1.5ms. This is a massive improvement, besting the current Mithril rewrite by 1.1ms (2.6ms overhead). At 50% mutation, 2.x gains an extra 5fps, going from 47fps => 52fps. The code changes are trivial:

Current JSONML implementation:

let render = (vm, dbs) =>
    ["div",
        ["table.table.table-striped.latest-data",
            ["tbody",
                dbs.map(db =>
                    ["tr",
                        ["td.dbname", db.dbname],
                        ["td.query-count",
                            ["span", { class: db.lastSample.countClassName }, db.lastSample.nbQueries]
                        ],
                        db.lastSample.topFiveQueries.map(query =>
                            ["td", { class: query.elapsedClassName },
                                ["span", query.formatElapsed],
                                [".popover.left",
                                    [".popover-content", query.query],
                                    [".arrow"],
                                ]
                            ]
                        )
                    ]
                )
            ]
        ]
    ]
};

2.x hyperscript:

let h = domvm.view.createElement;

let dbmon = (vm, dbs) =>
    h("div", [
        h("table.table.table-striped.latest-data", [
            h("tbody", dbs.map(db =>
                h("tr", [
                    h("td.dbname", db.dbname),
                    h("td.query-count", [
                        h("span", { class: db.lastSample.countClassName }, db.lastSample.nbQueries)
                    ]),
                    db.lastSample.topFiveQueries.map(query =>
                        h("td", { class: query.elapsedClassName }, [
                            h("span", query.formatElapsed),
                            h(".popover.left", [
                                h(".popover-content", query.query),
                                h(".arrow"),
                            ])
                        ])
                    )
                ])
            ))
        ])
    ])

If anyone still wishes to use JSONML (and for migration purposes), something like a domvm.jsonml module will be made to preprocess old-style templates into a properly formed vtree. This way, with known opt-in overhead, you can still use JSONML definitions:

let jml = domvm.jsonml;

var tpl = jml(["div", {},
    ["br"],
    ["table",
        ["tr"]
    ],
]);

I'm continuing to test which aspects of 1.x imposed penalties that were paid regardless of actual usage. One thing that may go away is objects as keys. this Map and Weakmap are slow, so keys will likely need to be either numbers or strings to be used in a js hash. This will allow much faster keyed matching and make destroyed view's dom reuse possible, among other things. Another thing that may change is ancestor redraw(level) and emit(ev, args...) may be moved out to modules as they only depend on each vnode having a parent reference, so can be cleanly implemented in optional modules.

As soon as I reimplement the important aspects of the lib and rewrite the tests, I will push the 2.x branch to Github.

I've been chasing a severe memory leak since Saturday, that seems to boil down to references internal to DOMVM. The situation is a relatively simple, but large (4148 elements), list of pairs of string rendered in a DIV (translations, source text and target text).

Every render grows memory significantly, until I crash the 32 bit browser at a little under 4 GBs.

The usage pattern in the debugger from a heap differential looks like this, where it all seems to end with initElement, as if the elements are being cached and never discarded:

Any thoughts on where to go with this? Is there something my code might be doing to cause old vNode elements to be retained from render to render?

Version 3.0.2.

Now that view closures can return {render: ...} objects, we should evaluate offering the option of returning {css: ...} as part of the mix, possibly accepting a JSS-style [1] stylesheet definition. Each vm is already tagged with a globally unique sequential .id, so the styles can be prefixed to isolate/prevent leakage. Another option is to prefix the defs with the function.name of the the view closure. This means all views created using the same closure would by styled uniformly. In both cases the view's root nodes would need the generated prefixes auto-appended to their className.

JSS pairs well with vdom/hyperscript style libs since it's js-assembled CSS, much like like js-assembled DOM.

This would make for a good isolated and high-ROI project if anyone wants to take charge, since it wouldn't require intricate familiarity with domvm's internals. 98% of it can live decoupled as an addon.

cc @grumpi, @yosbelms, @lawrence-dol

[1] https://github.com/cssinjs/jss

Motivation

Find a sibling, children, or a node with a complex related position. Find a node or a vm inside the tree.

Proposal

Two methods for vm and node. Those methods are down and up.

down: finds a item which fulfill the specified condition in the tree starting from the children of the node in question. Example:

var node = vm.down('someKey')

Finds a node or vm with that key starting from the vm children

up: the same with down but iterating over parents up in the tree.

var parent = vm.up('someKey')

Find a ancestor whith someKey key.

Usage example:

// root view with 2 keyed children
function RootView(vm, data){
    return function(){
        return ['div'
            [ChildView1, data, 'ch1']
            [ChildView2, data, 'ch2']
        ]
    }
}

// children view 1
function ChildView1(vm) {

    function click() {
        // redraw a keyed sibling
        // without redrawing the parent
        vm.up().down('ch2').redraw()
    }

    return function() {
        // execute update on click
        return ['button', {onclick: update}]
    }
}

// children view 2
function ChildView2() {
    ...
}

ChildrenView1 redraws the sibling without triggering redraw in the parent.

Another problem which does not show in a simple fiddle.

My application does not use routes. When I add domvm.view.config({ useRaf: false }); right before mounting the root view, I get an "impossible" exception on first redraw:

19:42:23.807 TypeError: vm.render is null
redraw() AppScript;01:105
receiveData() AppScript;01:595
init() AppScript;01:592
MdlHostReplay() AppScript;01:605
view() AppScript;01:544
createView() AppScript;01:92
init() AppScript;01:542
AppMain() AppScript;01:549
<anonymous> App:24
1 AppScript;01:105:86

Inspecting the vm object, it does indeed not contain a render function. All I need to do to fix things is remove that line. (I only added it because your fiddle had it and I was checking to see if it impacted #56.)

Also, it doesn't appear to matter what you supply for config; even an empty object causes the exception.

Hey @mikegleasonjr,

Before you hack up Mithril, take a look at domvm. I had similar issues with Mithril as the ones you've been discussing. Personally, I wanted to gut and/or externalize the "magic" and make it opt-in, have the framework be both concise and no-surprises as to what the internals were doing. I eliminated global auto-redraw and made it an explicit thing and made all sub-components independently redraw-able. I took some of the great ideas of Mithril and domchanger and wrote a new animal. There is less structural enforcement, so you can compose apps as best fits you needs. I am still writing some demo apps to showcase its usage in complex situations, such as http://threaditjs.com/. Currently, it's 2x faster than Mithril on dbmonster and has nearly identical syntax for templates, so porting a small app for investigation shouldn't require massive changes.

Router is almost ready but still has a couple bugs w/ the History api to fix.

Mithril's auto-redraw observers are implemented fully externally in /src/watch.js. For example, this is how opt-in global auto-redraw works in domvm with props:

function randInt(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;
}

// a view
function PersonView(vm, person) {
    return function() {
        return [".person",
            ["strong", person.name],
            " ",
            ["em", {onclick: randomizeAge}, person.age],
        ]
    }

    function randomizeAge(e) {
        person.age(randInt(0,100));
    }
}

// create an observer
var w = domvm.watch(function(ev) {
    maryVm.redraw();
})

// some model/data
var mary = {
    name: "Mary",
    age: w.prop(25),      // use observer
};

var maryVm = domvm(PersonView, mary).mount(document.body);

I'd be happy to answer any questions about how to get specific things done if you're coming from Mithril.

I don't plan to support IE8, so if you need that, please ignore this message :)

cheers!

I've been dancing around this issue since #60, but it's getting progressively more difficult. How would you recommend that a decoupled data-model which needs to trigger redraws on the vm that uses it be constructed?

The essential problem being that the properties of the model can't be created until the vm reference is available, but the model wants to be created before the view and injected into it.

var model=new DataModel();
var view =domvm.view(new DataView(model)); // or (new DataView(),model)

But DataModel needs the DataView view-model to do the moral equivalent of:

var w=domvm.watch(function() { vm.redraw(); });
...
exported.someProp=w.prop("default");

So the model can't be injected into the view, and the view can't be injected into the model. I can't see a clean way to do this.

@lawrence-dol @barneycarroll @isiahmeadows @pygy @mindeavor @stevenvachon @kuraga @Zolmeister @ciscoheat @tivac

Hi guys, thought you may find this interesting....

I've been evaluating isomorphic, component-based, pure-js-template vdom frameworks for a while and something about each one didn't feel "right" to me. For Mithril, it was the somewhat odd MVC terminology/architecture [1], the always-global redraw and speed was not always great. Afterwards I evaluated domchanger, which was small and minimal, but it too was somewhat slow and the component architecture was close, but still didnt feel quite right [2]. Other issues still with virtual-dom. I looked at the blazing fast Inferno and Cito but didn't quite like the verbosity.

[1] https://github.com/lhorie/mithril.js/issues/499 [2] https://github.com/creationix/domchanger/issues/5

So I did what any self-respecting coder suffering from NIH syndrome would do: I wrote yet another vdom lib. It's an interesting mix of ideas from different frameworks and it's near cito in terms of perf on dbmonster and speedtest (see /test/bench). The docs are still a work in progress, but the main API can be seen in the README of this repo. I'm finishing up implementing some of the good ideas from Mithril for magic auto-redraw (m.prop, m.withAttr, m.request) on top of the core. The plan is to leave the Promise and ajax/fetch implementation up to the end user, but add support for handling promises if provided by the user where it makes sense. Routing is also open to evaluation.

The focus has been speed, isomorphism, concise templates, isolated components, minimizing domain-to-view coupling or having to impose a specific structure onto domain models.

DBmonster demo: http://leeoniya.github.io/domvm/test/bench/dbmonster/

I would appreciate some feedback if any of you are interested and have time to test it out, otherwise please ignore/unsubscribe from this thread :) Feel free to ask any questions about how to accomplish specific tasks.

Here's a quick demo of how to compose multiple components and perform independent sub-view redraw. Note that this is just one example, but you don't need create models via constructor functions, they can be plain objects or arrays as well - the coupling can be even looser and external to the models entirely. Nor are models limited to a single view, you can create as many views of a single model as you required and compose those as needed.

Code below also on jsfiddle: https://jsfiddle.net/0Lt4kzLt/

// domain model/data
function List(items) {
    this.items = items;

    this.view = [ListView, this];   // minimal view coupling: [viewFn, model/ctx, _key]
}

// view
function ListView(vm, list, _key) {
    // any view state can be stored in this closure, it executes once on init

    // export the vm back to the model so `vm.redraw()` etc can be invoked from
    // outside this closure. not required but you'll usually want to.
    list.vm = vm;

    return {
        render: function() {
            return ["ul", list.items.map(function(item) {
                return item.view;
            })];
        }
    }
}

function Item(name, qty) {
    this.name = name;
    this.qty = qty;

    this.view = [ItemView, this];
}

function ItemView(vm, item, _key) {
    item.vm = vm;
    return {
        render: function() {
            return ["li", [
                ["strong", item.name],
                " ",
                ["em", item.qty],
            ]];
        }
    }
}

var items = [
    new Item("a", 5),
    new Item("b", 10),
    new Item("c", 25),
];

var myList = new List(items);

// this root function inits and returns the vm of the top-level view but since
// we also export it to <model>.vm, we don't need to use this returned one
var vm = domvm(myList.view);

// append it to a container
myList.vm.mount(document.body);

// now we can modify an item and redraw just that item
setTimeout(function() {
    myList.items[0].qty += 10;
    myList.items[0].vm.redraw();
}, 1000);

// or remove one, add a couple, mod some and redraw everything
setTimeout(function() {
    myList.items.shift();

    myList.items.push(
        new Item("foo", 3),
        new Item("bar", 66)
    );

    myList.items[0].name = "moo";
    myList.items[1].qty = 99;

    myList.vm.redraw();
}, 3000);

cheers! Leon

...continuation of #101

The view layer is now in final form.

Hopefully this discussion will be the last needed prior to v2.0.0 release and focused mostly on ironing out the router.

Some internal refinements have been postponed till after 2.0.0:

• Exposed ref cleanup from ancestors when unmounting subviews. The fact that they can also be namespaced makes this somewhat tricky and possibly expensive.

Features that will be considered for exploration post-2.0.0:

• fragment views
• dom recycling of unmounted views
• internally using addEventListener instead of on* props. This would allow things like ontransitionend which cannot be bound using props. Tracking a registry of attached events and patching them in all forms (including delegation and parameterization) makes this tricky/possibly expensive.

Recently, as my app has grown more complicated, I have been seeing uncaught exceptions in event handing at:

function handle(evt) {
	let elm = evt.currentTarget,
		dfn = elm._node.attrs["on" + evt.type];
                //        ^^^^^ -- TypeError: can't access property "attrs", e._node is undefined

	if (isArr(dfn)) {

I am pretty sure that these are race conditions with events that get delivered just after the DOMVM structure is torn down. I can't find any means in user-land to either handle or suppress them, and they are difficult to replicate, happening "occasionally" in production (where they are harmless, but look really ugly).

@leeoniya : Do you have any in-principle objection to adding a null check, either the modern elm?._node... or the older elm._node && elm._node...?

This seems inescapable in my case, where I have a controlling app loading other DOMVM apps in iframes, and the iframe can be closed at any time by the user, resulting in the framed app being torn down at any arbitrary moment.

@leeoniya

I am opening this as a new issue because I want others to be able to find it easily, and I don't want to confuse the issue with the recent enhancements to event handling (#235). So this should be food for thought (I would have opened a discussion item, if discussions were enabled). I should note up front that I don't really have a big dog in this fight, since I don't use this and with recent changes I can now live with simply always using parameterized handlers.

There remain four ways in which DOMVM parameterized event handlers (henceforth p-handlers) are inconsistent with JavaScript event handlers (henceforth e-handlers):

1. The this for e-handlers is the current target; for p-handlers it's the current vm.
2. The first argument for e-handlers is the event; for p-handlers the event argument is after whatever arguments were attached in the handler declaration.
3. The only argument for e-handlers is the event; for p-handlers DOMVM implicitly adds node, vm, and vm.data.
4. The onevent handlers are not called for e-handlers, and they are for p-handlers.

My issue with these differences is that none are technically necessary, and the differences create additional cognitive load and code fragility for me. Given that there's no longer a performance penalty for one or the other, I feel the differences are no longer technically justified. Note that I am not intending to speak to compatibility concerns -- that alone might render the entire discussion moot.

When I am deciding between an e-handler and a p-handler the only factor in view is whether or not I need to bind context arguments. Often, as the design shifts, and especially when I am first developing a component, a specific handler will change from normal to parameterized, or vice versa. Doing so makes the existing handler code broken in subtle ways, and it's easy to forget one of them, which becomes a runtime error, often a fatal one, that occurs only when that event handler is actually triggered. Painful to test and easy to miss.

The cognitive load increase is related, but applies to every handler I write -- is it an e-handler or p-handler; does it have arguments of evt,vm,nod,dta or just evt. Will the onevent handler be called or not (if I am using an auto-redraw system this could be critical). For programmers accustomed to this, I imagine having this be the current target in one context and the vm in another would be a constant source of frustration.

As reflected in my recent pull request these issues could now be easily addressed, and though doing so would break compatibility a case could be mounted that these are bugs.

The changes would be:

1. Bind this to currentTarget.
2. Always use the exec function.
3. Bind added arguments after the event, so instead of (...,evt,node,vm,data) use evt,...,node,vm,data).

The argument for #1 is purely consistency with JavaScript in general. The this value is always current-target, for every event handler I see in every JavaScript context.

The argument for #2 is that the extra arguments do no harm and consistency within DOMVM code is better than inconsistency. This is the one that is the least important; there seems to be some defense for only adding the DOMVM arguments to p-handlers, so I lean toward doing this, but not strongly.

The argument for #3 is that the event is the "fundamental" JavaScript argument, the explicitly declared arguments are context-specific, and node, vm, and data are implicit DOMVM "value-added" arguments. The event argument is always there, and it's always first, for every event handler I see in every JavaScript context -- the precedent for this is overwhelming. The explicit added arguments specified in the declaration seem to be naturally expected next, then finally the implicit DOMVM arguments.

As I said, food for thought; and in my opinion worth a major version bump and a breaking change to remove this constant source of friction.

the current dom insertion/removal/reordering reconciler [1] relies on 1:1 vnode-to-element mapping. this design prevents proper implementation of fragment vnodes, which in turn forces all views to return a single defineElement() vnode.

to resolve this impasse the reconciler must be:

1. modified to use the old vtree rather than the dom. this is fairly straightforward.
2. augmented for handling fragment vnodes. this is a bit more involved but workable.
3. optimized to do parent-down rather than children-up reordering. this can significantly reduce the DOM load by not doing meaningless DOM ops. for instance, in React's fragment impl, a 12 fragment reversal (with in-fragment reversal) results in 34 appendChild calls [2]. the ideal count should be 23 appendChild (or insertBefore) calls. this appears to translate to ideal fragment revrsal (11) followed by in-fragment reordering (23). the issue in domvm's case is that it has will/didReinsert lifecycle hooks, so rather than calling 1 per move, it would call multiple (one for each useless move). i think this nicely illustrates the perf overhead that can grow exponentially in dealing with fragments.

[1] https://github.com/leeoniya/domvm/blob/3.x-dev/src/view/syncChildren.js [2] https://codepen.io/anon/pen/zpdRKQ?editors=1000

i've started writing a domvm.d.ts file to make domvm pleasant to use with VSCode. so far i'm going through the following resources/examples written by people more familiar with TS:

https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html https://basarat.gitbooks.io/typescript/docs/types/ambient/d.ts.html https://github.com/hyperapp/hyperapp/blob/master/hyperapp.d.ts

it's likely the initial version will not be optimal and could be reduced with generics, etc. if anyone has TS experience, i'd appreciate any improvements or recommendations.

cc @lawrence-dol @tropperstyle @iamjohnlong @Veid @logaan @sabine

it would be nice to have some declarative transition support in domvm. i'm not sure what the api should look like, maybe {_trans: }, or if it can be an external plugin that will just set up the proper hooks as i do in the ModalStack [1] demo [2]...which is not general enough, but some bits can be adopted perhaps.

api proposals and/or fiddles now being accepted!

http://johan-gorter.github.io/maquette-demo-hero/ https://github.com/zaceno/hyperapp-transitions https://rawgit.com/snabbdom/snabbdom/master/examples/hero/index.html

cc @iamjohnlong @sabine

[1] https://github.com/leeoniya/domvm/blob/3.x-dev/demos/ModalStack/index.html [2] https://cdn.rawgit.com/leeoniya/domvm/3.x-dev/demos/ModalStack/index.html