[Drew_]

I don't know if you haven't had much experience with templating engines, but having the ability to write programmatic expressions to make a layout dynamic is a basic necessity that pretty much every known templating engine has. "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does and it works pretty well in practice.

[zkldi]

My issue isn't the existance of programmatic expressions (yeah, it's the point of templating languages), but more that the way vue (and angular) do it is a mess of syntaxes that creates a really, really strange template.

The lodash example is the main critique because that is not JS, but it involves evaluating JS - it's created its own programming language with its own rules -- when one was right there from the beginning!

[Drew_]

Like any templating engine there's always just enough power given to have the ability to write something stupid or complex in the template. Again not really a problem in practice.

The scary underscore expression you're referring to can easily just be written as a reversedList variable in "normal" JS and get referenced plainly in the template. So the template expression syntax never has to be as messy as you might think it is.

[zkldi]

The "scary underscore" expression isn't scary because it's an underscore, it's because it implies the evaluation of JS, such that you could (and obviously wouldn't) do things like

    v-for="x in console.log('hello world!') && fetch('/') && [1,2]"

(my syntax might be off since I don't use Vue, but the merit should still apply)

My point is that when your templating language starts doing things like this (and inevitably, all of them do) - you've created a new programming language that is generally less thought out as one than deliberately made programming languages. Although the above for loop is evaluating JS, the syntax is decidedly not JS.

[EugeneOZ]

Angular doesn’t evaluate the code of the template. Example with lodash will not work out of the box in Angular.

[dragonwriter]

> "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does.

Its not, though. JSX-based solutions (not just React, but Solid and others) don't (actually, neither do many frameworks with more traditional-looking templates, including, AIUI, Vue, actually compile templates to render functions, so it just looks like old school “string with embedded code which is evalled” ttemplates)

[Drew_]

I know it's pedantic but this is still JavaScript we're talking about not binary so the "compiled render function" is still ultimately just "a string that gets evaled".

In any case the implementation details aren't important it's what it appears to be that is apparently the problem.

[zkldi]

> it's what it appears to be that is apparently the problem.

Yep, Someone mentioned in another part of this thread that Vue compiles most of this out before production, so my remaning confusion pretty much stems from the DSL being a mishmash of html attribute context, vue custom syntax, and evaluated JS.

[lmm]

Templating is the wrong approach. Component-based approaches where you use polymorphism rather than putting logic in your templates are much better. Look at Wicket for a HTML UI framework done right, IMO.

[masklinn]

People like templates, and the clear and declarative correspondence between input and output.

You can write React without using JSX, and I assume Vue without templates, but unless the components system has a declarative layer so thin it might as well be templates (e.g. elm, or clojure’s hiccup) and it is entirely expression based, they’ll want templates.

Wicket looks like absolute nonsense of the worst kind. It completely reminds me of Struts and Spring and friends, and that is not a positive comparison.

[lmm]

> People like templates, and the clear and declarative correspondence between input and output.

You don't get that clear correspondence if you can have logic in your templates, and even supposedly simple expression languages in templates somehow always end up growing ifs, looping constructs and so on. Plain HTML fragments are good, but they need to be kept absolutely simple.

> Wicket looks like absolute nonsense of the worst kind. It completely reminds me of Struts and Spring and friends, and that is not a positive comparison.

I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

[masklinn]

> You don't get that clear correspondence if you can have logic in your templates

You absolutely do.

> I don't understand your position at all. The problems of Struts and Spring are the problems of templates only more so - if I were to make a spectrum I'd have Struts (and Tapestry) at one end, Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

The struts I got to use was full of "smart JSP custom tags" because "components are the right way" and subclasses all the things, it looked exactly like the examples I see of Wicket: keep bouncing through layers and files of useless nonsense because all the logic has to be out of the markup but all of the markup has to be out of the code, and formatting a list takes you through 3 templates and 5 classes.

> Wicket (and hiccup) at the other, and traditional templates somewhere in the middle.

That makes no sense whatsoever. Wicket and hiccup have nothing in common.

[lmm]

> The struts I got to use was full of "smart JSP custom tags"

Which is very much the opposite of how Wicket does things: there are no custom tags, the templates are inert HTML and there's a very small, non-customizable set of wicket tags/attributes (IMO the right way to do it is just IDs).

> That makes no sense whatsoever. Wicket and hiccup have nothing in common.

What they have in common is that all your logic is in code, not markup.