YAVDOM about marionette-vdom

[samccone]

@aMarCruz if you would like to open a PR to switch to this I think everyone would be more than willing to take a look at it. We have extensive tests so try it out and let us know!

[themindfuldev]

hi guys!

@aMarCruz do you know if maquette would allow the following transformations:

• String -> VDOM
• DOM -> VDOM

We need both, the 1st to render from a template (using any template engine as Handlebars, HTMLBars, Underscore, dust.js, Jade) and the 2nd one for when we instantiate a View passing the el as an existing DOM element.

I just had a look on Maquette and all the examples are using the h() method. Is there any other way to create VDOM with Maquette.js?

[aMarCruz]

Thanks @samccone.
and I don't think so, the transformation string->vdom should be maked by the template, at build-time, generating js modules ready to render, with slots ready to be data-injected by a minimal, lightweight runtime. Maquette merges DOM and VDOM, if dom element exists at time the vdom is constructed, but I don't really know, I don't having time to test it.

(i'm sorry by my "english", this is a Google traduction :))
Your work is very good, really.
One or two years ago I would have been happy using your plugin, but now, I'm seeking (as many others) the best alternative for mobile sites. We need a fast and lightweight, decoupled componenrs.

This is the reason why there are so keen to get rid of jquery, for example. It's too heavy. So we look for frameworks based on lightweight components, and technologies as virtual-dom, html5, and CSS3.
The must used framework (Angular) is taking this path in 2.x, giving back to their 1.x base, and even at the risk of losing many of them.

I see great projects like https://github.com/joelrich/citojs or https://github.com/bobris/bobril, riot, mithril, etc. but still inmature... in the other way, vdom in backbone (or marionette) is exciting!
sorry, sometimes I miss the days of dBase III, when we did not have much to choose where...
cheers.

[aMarCruz]

The guy at t7js is using (pre)standard ES6 tagged template strings to convert js strings to vnode. Implementation is ridiculously simple. Latest FF supports ES5 TTS natively, no es6to5 needed. In other browsers w/o ES6 support, we need Babel or Typescript 1.5 transpiler for convertion, the resulting js will work with the same t7js runtime function.

See https://developer.mozilla.org/es/docs/Web/JavaScript/Referencia/template_strings#Plantillas_de_cadena_de_texto_con_postprocesador
and https://gist.github.com/WebReflection/8f227532143e63649804 (String.prototype.template.js)

[themindfuldev]

hi @aMarCruz - thanks for your lots of valuable input!

The main roadblock here is that Marionette is mean to be template-agnostic, ie, you can use any template library, even though it comes with underscore.js you can use your favorite template library like Mustache, Handlebars, dust.js, Jade, etc. And there are many apps around using Marionette with different template libraries.

And all those templates will output a String.

So right now we get the response from String, and transform from String to VDOM using our VDOM library.

However as you are saying, as Maquette doesn't do this step, and you suggested that the template itself should make this transformation.

That is possible in theory, however one would need to write plugins for every template library to transform from String to VDOM - and eliminates the flexibility of enabling "any template library to be used over Marionette".

Thus, marionette-vdom is doing this transformation AFTER the template response is retrieved.

Would you see another solution for this scenario?

BTW I have already though about creating a more efficient bundle, which would use one specific template engine + VDOM and eliminate this extra layer, but that would not be that much reusable as the generic solution. But maybe it is a good idea after all.

[aMarCruz]

hi @TiagoRG, I understand.
However, I think the plugin using existing libraries, is the path, because works in build-time.
Something like this:

+--------------+
| Mustache.JS  |
| htmlbars.js  | -------> mustache transformation plugin ---> v-dom code.
| hogan.js     |
+--------------+
+--------------+
| jsx          | -------> JSX transformation plugin --------> v-dom code.
+--------------+
+--------------+
| ES6 tts      | -------> Babel, TypeScript 1.5, ES6 native --> v-dom code
+--------------+                (with plugin a la t7js)
+--------------+
| mithril m()  | -------> Mitril transformation plugin -----> v-dom code
| compatible   |
+--------------+
...etc.
+------------------------------------+
| hand-written v-dom javascript code | ---> (no plug-in) ---> v-dom code
+------------------------------------+

The v-dom code generated with the transformation plugin is a module (js native) with functions returning simple, low-level, js objects:

export.mytemplate = function (data) {
    return [
        {tagName: "div", attributes: { id: "div1", class: "foo" }, children: data.text },
    ];
};

Your module don't need know about the user plugin, this is user's choice.
And your module is more cleaner and lightweight. You are dealing with the js object(s) returned from export.mytemplate(data).

Obviously you and others should write these plugins, but I'm thinks this is not complicated.

Ex. https://github.com/latentflip/domthing is using Mustache for generating js code (in build-time) returning DOM objects in runtime.
This is my idea.
Does makes any sense?

[themindfuldev]

@aMarCruz that is very clever. I agree that doing this step during the build-time would be far better for performance versus making this transformation on runtime.

We would then need this component to transform the template from template engine to VDOM.

This would optimize it for the majority of the scenarios. marionette-vdom would simply receive the template which would be returning VDOM elements.

Anyway, I believe the marionette-vdom library would still need to support templates the old way, because sometimes such templates are given during runtime as well.

[aMarCruz]

I see, hot-swap templates w/o touch code. I think about this.

[themindfuldev]

That has been a great discussion but I will close this issue for now since the conclusion didn't result in a code change. Thanks everyone!