These are chat archives for tiagorg/marionette-vdom

1st
Feb 2015
Tiago Garcia
@tiagorg
Feb 01 2015 07:14

hey @M3kH - the lib virtual-dom is using Saucelabs to provide a full chart of cross-browser testing -> https://github.com/Matt-Esch/virtual-dom

you are totally right, it would be very interesting to do something similar here. I will have a look on this tomorrow.

regarding question 2, I’m not quite sure I got it. we are currently trying to extend Marionette instead of modifying, in order to be less dependent on the parent classes evolution and so be more compatible with different Marionette versions
Mauro Mandracchia
@M3kH
Feb 01 2015 12:43

@tiagorg Yes I got, and I'm sorry to criticise this cool work!
My preoccupation start to the fact this would not be part of Marionette but just an add-on, since this is the approach; I see the limitations it brings.

For instance, I can clear see by the code that we do:

"string tmpl" -> _.template() ->  template(data) -> string -- to -- dom --> diff and append;

Now has I was used to distribute compiled templates on my CI just to make sure to save one step to the browser; IMHO should be like this:

"string tmpl" -> _.template() + vdom -> template(data) -> diff and append

In this way templates can be optimised before.

IMHO this project should be or detached by Marionette it self and be one step before has replacement for string templates engs. Or embraced by Marionette has template engine. In this way we could really compare with new dom framework approach.

Then looking around I found really interesting this library https://github.com/gcanti/uvdom try to take a look at it, maybe can be inspiring.
I will try to do a prof of concept to implement mustache -> uvdom -> (your vdom engine) -> your tmpl();

Tiago Garcia
@tiagorg
Feb 01 2015 22:18
@M3kH you are correct about this limitation, it as far as I understand this is the only way to keep full compatibility with any templating approach - once Marionette is non-opinated
just for the record there have been some thinking about using HTMLBars on a very similar regard and @jmeas was looking into it.
Marionette’s default assumpion is that a given template will come (and renderize) as a String. As you can see here: https://github.com/marionettejs/backbone.marionette/blob/master/src/item-view.js#L89
and there is also a whole component for that. Marionette.Renderer https://github.com/marionettejs/backbone.marionette/blob/master/src/renderer.js
Tiago Garcia
@tiagorg
Feb 01 2015 22:23
so maybe that would be the place to perform such early-stage optimization to VDOM as you are suggesting - https://github.com/marionettejs/backbone.marionette/blob/master/src/item-view.js#L68

pretty much, modify _renderTemplate method to immediately VDOMize the template before applying the data

I just couldn't see how can this be done generically, before applying the data, let’s say a solution that would work for any templating engine - because I believe the way each templating engine binds its data would be particular to each engine

for instance, Handlebars has helpers, so before rendering a piece of data, Handlebars would internally verify if that name resolves to a helper, or an instruction (if, unless), because those are reserved words for Handlebars
I have never tried but I believe that Handlebars would never allow you to have a data attribute named “unless” while this might be possible for other template engines…
Tiago Garcia
@tiagorg
Feb 01 2015 22:28
anyhow.. @M3kH if this is possible to be overcomed, it will surely be better than this current approach
please let me know how your POC with mustache goes, I believe this has a great potential to improve this approach as well
:)