Hacker News Reader

Comment by namelosw | Hacker News Reader

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them.

It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript.

For example, a framework Foo does not have the concept 'else' at all in HTML template. Another framework Bar has an 'else' like <div bar:else="expr" />, but the scope of else is totally different from another framework Baz or JavaScript itself.

JSX on the other hand, is straightforward -- when you open a curly bracket, it's just JavaScript expressions -- map, condition, lexical closure, everything works out of the box.

View on HN

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.

> It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte)

This is the most ridiculous thing I hear when people compare frameworks.

I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either.

Also, my dude, there's like half a dozen rules when it comes to vue templates. Jsx has lots of small rules about component names and things like class vs classname as well.

As for putting javascript expressions in your templates... Each to his own I guess, because imo it's a pretty bad anti-pattern to put an extensive amount of procedural code in the template code. Again with vue, using things like computed properties in single file components (SFC) makes it very easy to read and maintain code.

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?

> Just like you can do anything in C++, but in practice it's a terrible language to work with.

It definitely beats working with JS for me.

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

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

You mean, wildly inconsistent templates: https://news.ycombinator.com/item?id=19199423 and magically bound JS https://news.ycombinator.com/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.

Reply on news.ycombinator.com