Anything with a DSL is evil. That's why I never liked Vue and don't understand its huge popularity - you get none of the functional benefits of React, you might get a minor speed increase, and you DO get to write code the old style with custom DSL and no clear components.

Don't forget to mention the poor (and complicated) editor support for "these custom HTML templating languages". JSX is very well supported in most editors.

With TypeScript you even get compile-time type safety for your JSX.

> Also, my dude, there's like half a dozen rules when it comes to vue templates.

You mean, wildly inconsistent templates: https://qht.co/item?id=19199423 and magically bound JS https://qht.co/item?id=17471199 (see code and comments at the end)

I am not sure inconsistent is accurate here.

Take the following for example:

    v-on:click="counter += 1"

    v-on:click="greet"

    v-on:click="say('what')"

Even without knowing vue, all of those examples are very straightforward in what they're doing. Just because the click event can take multiple options doesn't mean that it's inconsistent.

And yea, it's more complicated than "everything in the brackets is javascript and you already know javascript so it's all super simple". If this is where the bottleneck is for you then, fine.

All I can say for myself is that I find vue's templating easy enough that it's a non issue.

The fact that it is restrictive because it's a DSL is a plus for me because it avoids some really ugly code that I've seen in some react projects where the programmer puts a tonne of js code into the templates which as I mentioned before I find an anti-pattern.

As for the magic... yea vue is more magicky, which is why I like it. It's a framework, it's supposed to magic away the stupid boilerplate code. In some ways this is going to be relative because there are people out there that think frameworks like react are too magic and require too much tool-specific knowledge when vanilla js can get the job done. And people that make this argument are technically right in the same way you're technically right that vue is more complicated than react.

> Just because the click event can take multiple options doesn't mean that it's inconsistent.

That's what inconsistency means. It has multiple v-* attributes and each has different rules on what it accepts.

> ugly code that I've seen in some react projects where the programmer puts a tonne of js code into the templates which as I mentioned before I find an anti-pattern.

JSX isn't templates ;)

> It's a framework, it's supposed to magic away the stupid boilerplate code.

I don't mind magicking away the boilerplate code. I do mind when it's once again so inconsistent in how it magics away that code. For example, in my second link multiple nested properties become properties of `this`, and then:

    // `this.isFolder` magically hoisted into `this` from
    //    `object.computed.isFolder`
    //
    // this.open can be set directly. Magic.
    //    Even though `this.open` magically hoisted 
    //    into `this` from `object.data` which is a function that 
    //    returns an object whose keys and values are hoisted 
    //    into `this`
    //
    // this.model.children cannot be set directly. Not magic

And so on.

Bunch of things going on there:

1 - things defined in data, computed, methods, and props can be accessed on the component directly as a shortcut. This is in the fairly short documentation and everywhere in the code examples. It's not inconsistent if you don't know the rule. It's like complaining that variable names in some languages can start with _ or other special characters but can't start with '1' or start with '2', or start with '3'...

2- and this.model.children definitely can be set directly, and it will be reactive. Unless you're passing an object literal without binding it or if it's not a data object, although I am not 100% sure on this since all my props are usually made reactive by vue and so they are bound. But I know for sure that code like this should work for sure because I've done it.

3 - I don't think that's the correct use of hoisted.

I feel like maybe you'd like vue a lot more if you gave it a chance and went through the documentation (which is pretty good, short and simple). I don't disagree that it has a little bit of magic, but it probably looks worse than it really is if you don't know the rules. Once you know a handful of rules, things are fairly easy to reason about. IMO, easier than angular, and sort of easier than react because there's less code.

I love Vue and I vastly prefer it instead of React (have even been using Nuxt lately, now that is some real magic) but that comment makes really good points about Vue!

JSX is clearly a second class citizen in Vue. Last time I tried, using TypesScript with Vue made JSX unavailable. And it was not documented, so the process was try, fail, look around, find the Github issue about this.

You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with.

For class part I'm sure it's just whatabouism...

And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you own that differs from JavaScript?

Haha fair enough, especially if you consider the book 'JavaScript' minus 'JavaScript the Good Part' meme.