5 ms·

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 bet

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.

preommr 7y ago
> 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.
- namelosw 7y ago
  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?
  - xfer 7y ago
    > 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.
    - namelosw 7y ago
      Haha fair enough, especially if you consider the book 'JavaScript' minus 'JavaScript the Good Part' meme.
- dmitriid 7y ago
  > 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 https://news.ycombinator.com/item?id=19199423 and magically bound JS https://news.ycombinator.com/item?id=17471199 https://news.ycombinator.com/item?id=17471199 (see code and comments at the end)
  - preommr 7y ago
    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.
    - dmitriid 7y ago
      > 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.
- idoubtit 7y ago
  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.
Rotareti 7y ago
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.
- bfrydl 7y ago
  With TypeScript you even get compile-time type safety for your JSX.
dirkg 7y ago
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.

preommr 7y ago

> 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.

namelosw 7y ago
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?
- xfer 7y ago
  > 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.
  - namelosw 7y ago
    Haha fair enough, especially if you consider the book 'JavaScript' minus 'JavaScript the Good Part' meme.
dmitriid 7y ago
> 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 https://news.ycombinator.com/item?id=19199423 and magically bound JS https://news.ycombinator.com/item?id=17471199 https://news.ycombinator.com/item?id=17471199 (see code and comments at the end)
- preommr 7y ago
  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.
  - dmitriid 7y ago
    > 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.
idoubtit 7y ago
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.

Rotareti 7y ago

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.

bfrydl 7y ago
With TypeScript you even get compile-time type safety for your JSX.

dirkg 7y ago

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.