[TL;DR] After 22 days of using DOMly

[devel-pa]

I hope I'm not annoying you with this. My 2 cents. Only theory, nothing concrete, yet.

Pros: Fast (not in IE), handlers, nice syntax (a bit confusing sometimes) Cons: No helpers (I prefer dedicated helpers, not global functions or local stuff, no code duplication, bla, bla, bla), Not compatible with handlebars (maybe not a cons, just unhappy 'cos I can't use my already made templates and helpers), not uglyfiable (damn, I hate that).

To sum up all the stuff I think is maybe better to have a runtime, a small one, something like this one: https://github.com/davidnormo/cleanshave/blob/master/src/lib.min.js

With such runtime you can achieve better compression and a way to add helpers.

Talking about IE looks like any string concat lib is faster than the DOM templating ones. No chance to beat that. Instead of fighting with doT templating engine (which looks the fastest in IE11, 2023 end of life, :cry: ) the runtime maybe would help to serve strings only for IE browsers ( document.documentMode !== undefined or whatever). Now, how to append strings instead of attaching DOM elements is another story.

[devel-pa]

Talking about helpers, maybe using your solution is a better way by having them in a global defined object or passing "mixins" with data.

Another stuff is to be able to compile the templates by mentioning if "runtime" will be used or not.

Third stuff is about not knowing how to give handler in case of string compilation, maybe a separate method (maybe "append") that will give the handlers using native selectors.

[devel-pa]

The bad news is that Spartan (which declares itself as Chrome) performs the same as IE11:

• fast cloneNode and innerHTML on unattached elements (not fragments)
• slow element creation

[devel-pa]

As an optimization proposal is "cloneNode at all cost"

You are losing that if you're using any function, so maybe a way to optimize a bit is to make external functions for for, if, etc. and return from each of them a node clone.

Also, for handle instead of attaching this["namedHandle"] a solution could be:

return function template() {
      if (!frag) {
        frag = anonymous();
      }
      var ret =  frag.cloneNode(true);
      var handlers = ret.querySelectorAll("[handle]");
      for(var i = 0; i < handlers.length; i++) {
        var h = handlers[i];
        this[h.getAttribute('handle')] = h;
      }
      return ret;
    };

[devel-pa]

I have no idea which is the faster: creating a new element or querySelectorAll.

The last idea is to build initially the elements with composed keys with "directives" (like domly) that contains all the things needed to replace the attribute and when data arrives to get those directives and set attributes of the cloned node accordingly.

[lazd]

@devel-pa thanks for the feedback. How are things at day 42? :)

[devel-pa]

I did what you've did, too :) Gone back to Handlebars after I hit the wall few times. Anyway, what I wanted to do is something between DOMBars and Cleanshave (and HTMLBars, which I think is too heavy) but I have to finish my project first as I get late hanging around.

[lazd]

@devel-pa thanks again for giving DOMly a try! What was the biggest wall?

[devel-pa]

@lazd Not being able to use functions with parameters for setting element attributes. Or at least it was the stopper for me at that moment. Maybe solvable, but, that's it. If you ever want to restart the work here I want to join in.

And by the way, nice Backbone stuff in your repository :D

[lazd]

@devel-pa, wait, you mean like this?

<button id="disabled" if-data.isDisabled(data.arg1,data.arg2)="disabled='disabled'">A Button</button>

It's supported, and there's a test for it (fixture, test).

[devel-pa]

@lazd The values that have to be written inside the class attribute should be returned by the function. Something like this, with 3 functions inside:

<button id="disabled" class="if-data.isOffset(data.arg1,data.arg2)=returnedValue if-data.isStarted(data.arg1,data.arg2)=returnedValue">A Button</button>

Maybe an edge usecase.