Code is just a string too, treating the 'code' inside the string literals after the v-for is just an extra level of syntax handling - The IDE I use (Intellij) can handle it just fine.

Also as a side note: I'd say the best thing about Vue isn't it's templating system, but the fact that it's truly reactive. In react, only rendering is truly reactive. If you have reactive variables that depend on each other, then you have to manually mark those dependencies. Vue can deduce that dependency graph automatically, which makes coding much easier. It's like a giant spreadsheet.

You won't ever have more than 10 characters at most in an attribute, and if you do you make a method for it and call the method.

The other alternative is JSX type stuff in react where you are injecting full JS into the templates which is like committing seppuku to me. Vue is so much nicer to use than react IMO, and I've used both extensively.

This is the part I don't really follow, though. Technically:

    <a href="print(1//3)"></a>

I'm like 60% sure that your "string' example is never run in production. So I believe that it gets compiled before vue even sees it (at build time, or dev-server compile time) into the standard method that vue is used to... a vue component:

    Vue.component('button-counter', {
      data: function () {
        return {
          count: 0
        }
      },
      template: '<button v-on:click="count++">You clicked me {{ count }} times.</button>'
    })

I guess my remaining alien issue is that the DSL for Vue is a mish-mash of JS, custom syntax, dom attribute context and possibly more?

All these frameworks try to solve what you're mentioning in different ways.

Obviously people have different opinions, but after seeing the way things are done from all these different frameworks, Vue is extremely "clean" and minimal feeling, while remaining extremely flexible. I have built multiple very complicated apps and there's nothing that I'm not absolutely DELIGHTED how it's solved, especially with the new composition API. It feels extremely elegant compared to the other ones I've mentioned.

Perhaps consider the alternatives, and you most certainly will have a much worse development experience if you're not willing to play ball with 2-way data binding (ie use html attributes to bind things, etc). As I said, other frameworks have tried other methods to minimize attribute use and they're excruciating to use. Ember is literally one of the most painful frameworks I've ever used to do even the most simple of things.

Also modern component-based JS frameworks all work the same way. The UI definition is a template that's compiled into a render function which produces the final output during runtime. Each framework uses different syntax: React uses JSX which is a domain specific language (DSL) that mixes HTMl-like tags into Javascript. Vue uses HTML with directives on top. Angular, Svelte, etc all use their own formats.

You can even mix and match (use JSX with Vue) or write your own render function if you want, but it's the same text->parsing->lexing->compilation cycle that every language goes through before turning into actual CPU instructions.

Again, it’s all just text in different syntax. Programming languages are just a very large and well defined syntax compared to a template language, but that’s all it is.

Vue’s directives offer just enough control to handle 99% of scenarios while remaining within HTML.

All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it, but compilation is the same fundamental process regardless of language or environment: https://en.wikipedia.org/wiki/Compiler

So yes it's all just text following a different syntax, and Vue's documentation already describes exactly what you can run: https://v3.vuejs.org/api/directives.html

Yup

> What actually does the compilation is irrelevant.

Nope. It is relevant. For the stuff you put between script tags there's at the very least https://github.com/tc39/ecma262 that you can look at and tell exactly what's going on with your code.

With Vue (and, yes, React and Svelte and Angular): who knows? It might very well evalueate strings at runtime for all we know.

> All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it,

Yup. It's an additional, different step before it can even get to the browser. The problem with this step is that for most of this code there's not even a coherent specification of what it is, and how it's compiled.

> and Vue's documentation already describes exactly what you can run

It really doesn't. For example, here's the "documentation" on v-for:

    Expects: Array | Object | number | string | Iterable

    <div v-for="{ a: 1, b: 2 }"></div>

What are you even arguing at this point? This isn't about compilation or strings anymore. You don't like Vue's specific DSL? Or you don't understand it? Or you found a problem with the documentation? Or do you need a full grammar and syntax definition before you can do anything?

It's basically any valid `for..in/of` expression but you can always solve your mystery of "who knows" by just looking at the source code: https://github.com/vuejs/vue-next/blob/master/packages/compi...

That Vue isn't "the same as text between script tags". Because "text between script tags" is fully specified, and known to the browser.

Vue's ad-hoc mish-mash of DSLs has to go through an unspecified series of transformations before it can even become a "text between script tags". And that's the issue not just with Vue, but with any other templating layers.

> but you can always solve your mystery of "who knows" by just looking at the source code

Ah yes. The good old "code is the source of truth" fallacy. Can you point to me where exactly in code it specifies this: `Expects: Array | Object | number | string | Iterable (since 2.6)`?

I'm not sure why you're stuck on this. Templates are just a more simplistic programming language. That's how so many IDEs can still provide help with them.

This isn't true at all though, because `for x in y` is invalid JS.

   for (variable in object) {
     statement
   }

You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string isn't the same syntax as JS" but I don't see what the point is. Why does it have to be valid JS?

Again, you can embed syntax within each other just fine. JSX has HTML tags inside JS. HTML has tags like <style> and <script> for other languages (regardless of what the default language is or what parses it).

So, for the last time, what's the actual argument?

   for (variable in object) {
     statement
   }

   item in items
   (item, index) in items
   (val, key) in object
   (val, name, index) in object

   v-for="item in items" :key="item.id"

for...in iterates over the keys of an object, but for in in vue iterates over the elements of an array.

It is you who doesn't think that loop does what it actually does.

Please read the spec and verify with your favorite JS runtime before continuing this argument.

    for (x in [6,1,6,2,6,3]) {
      console.log(x);
    }

Also Vue's directives are not JS. It's a separate DSL. I've repeated this enough so I'll end this discussion here.

This is not true for javascript at all.

    for (x in [6,1,6,2,6,3]) {
        console.log(x);
    }

Either way it's entirely consistent: an iterator that works on both objects and arrays and prints the keys without guaranteeing order. Does that clear up the confusion?

You get type checking, linting, syntax highlighting etc.

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"

    v-for="item in _.reverse(items)"

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.

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!

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.

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

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.

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)

In any case the implementation details aren't important 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.

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.

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

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.

  {{ for item in items | orderBy 'field' -1 }} ?

To be clear, I vastly prefer Reacts approach of putting HTML into JS, rather than Vue/Angulars approach of putting JS into HTML.

Both approaches are valid, and each comes with its own set of tradeoffs.

Webstorm has zero problems letting me refactor it, because it can parse vue code in .vue files. This is seriously a non-issue.

WebStorm and its bigger brother IntelliJ IDEA can handle this.

They're way, way overengineered for the very limited use cases they're designed for.

If you're going to ditch the browser API's and re-write the world in Javascript, why not take into consideration all of the history of GUI development and do it right? I.e., make a real layout engine, proper widget hierarchies, real encapsulation, etc.

Instead there's some sort of frankenstein in-between state where you've ditched all the benefits of native browser API's but haven't arrived anywhere that's a true paradigm shift.

TL;DR - yeah, they make some things easier to reason about, but for any sort of non-standard webapp you'll still need to write an equivalent mountain of hacks and framework adaptors.

You answered my questions with a bunch of theoretical non-answers that comes off like a tech purist who hasn't actually used the technologies but has a lot of opinions about them. Do you have a lot of experience designing non-trivial/complicated web apps with very heavy front-end features? "layout engine", "widget hierarchies" what _exactly_ does that mean in the context of designing something as complicated as Google Analytics/FB Biz Manager using javascript. If you are proposing not using primarily JS logic but rather server logic, or not as a SPA (or isometric hybrid like nuxt/next), then that makes me want to hear your answer even more.

Answer the question of: how would you do it?

another dsl? mind-blowing! where haven't I seen that.