If it's a template then it's a very complex one, and under closer inspection it reads almost like storing code in a string and evalling it.
Let's say we want to iterate over commits in reverse. A google shows that we can do something like this:
v-for="item in items | orderBy 'field' -1"
So, there's pipes now, and Vue has essentially re-invented a programming language inside HTML attributes. But then comes this example below it:
v-for="item in _.reverse(items)"
And this line is terrifying! If this string is able to use lodash, then that means it's able to access the JS global scope, and therefore is very powerful - yet the resulting template is nonsense js, but still at some point involves JS evaluation?
Maybe I'm missing something though - I don't use Vue and if something is this big with this approach, I'm definitely missing something.
EDIT: A search for *new Function(` calls in the vue github repository shows quite a lot of code that essentially evals strings.
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.
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!
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.
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.
> "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)
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.
> 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.
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.
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.
> 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.
> 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.
> 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.
I feel like you're getting hung-up on the fact that the template directive is also a valid attribute and not something similar to jinja - but that's just syntax
This has been the debate of templating systems for as long as I can remember. Do you want your looping construct to use the same syntax as your markup language (so all the tools you use that operate on the markup "just work", without any modifications)? Or do you want to use the same looping constructs as the language you are programming in (so there's no need to invent or learn a DSL built on top of a markup language)?
Both approaches are valid, and each comes with its own set of tradeoffs.
Yeah well, its not really HTML - its JSX and it reads quite differently. Most folks who create HTML prefer to read HTML not Reacts domain language. HTML is a documented world-wide standard implemented by web-browsers. JSX is not.
You are trying to discuss things you have never tried in practice, just saw some examples in the docs. Your opponents are trying to explain this fact politely.
Let's say we want to iterate over commits in reverse. A google shows that we can do something like this:
So, there's pipes now, and Vue has essentially re-invented a programming language inside HTML attributes. But then comes this example below it: And this line is terrifying! If this string is able to use lodash, then that means it's able to access the JS global scope, and therefore is very powerful - yet the resulting template is nonsense js, but still at some point involves JS evaluation?Maybe I'm missing something though - I don't use Vue and if something is this big with this approach, I'm definitely missing something.
EDIT: A search for *new Function(` calls in the vue github repository shows quite a lot of code that essentially evals strings.