Actually, was thinking on it and I really used the wrong example -- or at least I used their most card-stacked example... and that too plays to "false simplicity".

A lot of these systems can make simple examples simpler, but harder examples harder, which is why they lead with their strength. If we move on to example #2 from that page, the markup again has a element that has no business in the markup or even stated AS markup.

<div id="example-2">
    <!-- `greet` is the name of a method defined below -->
    <button v-on:click="greet">Greet</button>
</div>

The new vue as it were is:

var example2 = new Vue({
    el: '#example-2',
    data: {
        name: 'Vue.js'
    },
    // define methods under the `methods` object
    methods: {
        greet: function (event) {
            // `this` inside methods points to the Vue instance
            alert('Hello ' + this.name + '!')
            // `event` is the native DOM event
            if (event) {
                alert(event.target.tagName)
            }
        }
    }
})

// you can invoke methods in JavaScript too
example2.greet() // => 'Hello Vue.js!'    

Now, if I were doing that in the upcoming elementals.js 4.0, again the only thing in the markup would be the DIV I was hooking.

<div id="example-2"></div>

Whilst for JS:

var example2 = make('button~Greet', {
    type : button,
    last : 'example-2',
    'data-_variables' : {
        name : 'elementals.js'
    },
    methods : {
        greet : function(event) {
            // `this` inside methods points to the Vue instance
            alert('Hello ' + this.name + '!')
            // `event` is the native DOM event
            if (event) {
                alert(event.target.tagName)
            }
        }
    },
    onclick : 'greet'
});

_.Node.method(example2, 'greet')(); // => 'Hello Vue.js!'        

Damned near code parity... the more complex the example, the more the pendulum swings in my favor.

NOTE in elementals 4.0 the "data-_variables" and "methods" are currently placeholders and not indicative of the final implementation.

This type of element and event construction is something I've been trying to steer elementals.js towards doing. It's not the concept of doing these things I have an issue with, it's the implementation that bugs me.

Markup for things that have no business even being markup? Methodologies that if 1:1 implemented in markup don't even EXIST if the CSP is enabled or prevent you from going "use strict"? NOT ACTUALLY using the DOM and constantly diving for the mentally enfeebled 'innerHTML'? I'll pass.

-- edit -- actually, my bad, the "this" would not be normalized if directly called. Hmm... interesting that part of their implementation. Whilst handy I'm not sure the overhead would be worth it.

Actually Steven Ventimiglia I really have to thank you for the poke on this... it has prodded me into reviewing what my team on elementals.js had proposed, actually try using the functionality, and utterly and completely reject it for doing things too much like the things I don't like about vue, react, angular, etc. I have ripped that functionality out by the nerts and am investigating if there's a 'better' way of handling this type of data interaction.

My team was putting too much data on the actual DOM object -- that's a really BAD idea even with data- attributes.

Though I may be abusing my powers as "benevolent dictator" on the project, throwing out days if not months of other people's work. Wouldn't be the first time.

No problem at all, Jason. I love reading your replies, like the ones above, because it's always a strategic deep-dive dissection that's focused on proactive improvement - whether some folks like it or not.

It's been a long time that someone's writing style reminds me of ye olde 2600 (2600.com). If you published a book, I would buy it.

I'm also slowly digesting Elementals.js, and it's well documented - so thank you for that. I think if more folks knew it was out there, it would be extremely popular.

elementalsjs.com