Guys, this is indeed an really cool feature for Marionette and I'm really looking forward in start to implements in some my side projects, just to see how it work and performs with some real cases.
Anyway, Really thanks to be away from the JSX, unfortunately they try to solve a problem so far from what they got from XHP, since hhvm is not a everyday case, I'm really happy to see emerging some alternatives in this way.
I think the dom it self is generic speaking a better approach to represent ui's and app status. So far is really a big advantage don't try to solve it with the gap of other languages like php has, in dom.
@samccone Yes you are right, but there is some controversial aspects for trust on it.
1) No cross browser testing, which vendors are supported? Same for dependencies, like html->vdom.
2) No embraced vision for Marionette it self.
Did you thinks this approach can be generic speaking more powerfull once is full integrated with a unique vision framework, whit some consolidate principles Backbone, give to us? And maybe get the vdom transpiler officially supported by the framework it self?
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.
@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();
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
@tiagorg Maybe HTMLBars is the best way to go and since would be part of ember.
I would try anyway to see if the uvdom approach can be useful since can compile templates for mercury and mithrill and react, which in the end would mean you can choose your vdom render engine and diff algoritm. Let's see! Anyway good initiative :+1:
deps: ['jquery', 'underscore'],
deps: ['jquery', 'underscore', 'backbone'],
deps: ['jquery', 'underscore', 'backbone', 'backbone.marionette']
is the config that worked for me
CompositeViewusing all VDOM
attachElContent()which probably wasn’t rendered from the VDOM before - https://github.com/tiagorg/marionette-vdom/blob/master/vdom-mixin.js#L35