I'm not sure I follow. To use the basic example from the link, as opposed to this:

  const listItems = numbers.map((number) =>
    <li>{number}</li>
  );
  return (
    <ul>{listItems}</ul>
  );

What's wrong with looping this way?:

  return (
    <ul>
      {numbers.map((num, i) => <li key={i}>{num}</li>)}
    </ul>
  )

> What's wrong with looping this way?

The problem IMO is that it's harder to read and write than:

    <ul>	
        <li v-for="num in listItem">{{num}}</li>
    </ul>

That's Vue's syntax, but any other templating language is more readable to me than JSX.

I find the JSX loop infinitely easier to understand what's going on. It's a javascript map. With your Vue example, what is listItem? An array? Can it be an object? Does listItem need a special decorator for v-for to be able to loop through it?

So many initial questions that just aren't there if you just use Javascript.

I'm not entirely sold on Vue, I've never used it before, and I'm happy to use JSX but the Vue template code is far, far clearer to me.

it's just plain for(x in list){ .. }

v-for="item in list"

if you need idx:

v-for="(item, i) in list"

pretty standard stuffs

Cool, but in JSX it's just javascript as you would write it anywhere else in your app, except encapsulated in braces. How is that not simpler for people who should be Javascript developers?

I thought the whole point was that you didn't have to write loops in Vue.js and yet here is a loop in Vue.js.

How does this actually work? When I see JS-esque code passed as a string I get a little queasy. Is this "eval"-ed so I can use real JS there? Or is there some Vue parser that reads this little mini language and interprets it? What is `listItem` exactly, and how does that template have access to the data represented by it?

When I'm trying to digest a bit of code, the superficial representation of what's present on the page is only half the battle - I also like to understand what it's doing under the hood. For me, then, JSX is way easier to grok than this bit of code, since I have a mental model of how JS works, and JSX is just a very small serving of syntactic sugar to compile an HTML like template into native JS. I know the transformations that are happening, and I can envision the code that it's being transformed into.

Templates have always been nice for basic examples. But now what happens if you only want to show odd numbers in listItem? It's not obviously clear how to do that in this example. Then you start adding in filters or Angular pipes. And the syntax grows in complexity until it becomes unwieldy. If you know the basic rules of JS, you already know how to achieve this with JSX. There's no need to go read the docs.

Haven't used VueJS but the obvious thing to me would be to do your data transformations before hitting the view code - separating view code from business logic.

So is this really a problem?

You don't always want to transform data, sometimes this is merely a UI concern...as in filtering, sorting, etc.

Yeah, so filter and sort it before you hit the view (and by this I mean the markup jsx or whatever) code, and problem solved ;)

Classic MVVM pattern

Then you're back at OPs original complaint which was that loops take you away from the markup you're currently writing.

Sorry, I shouldnt have said 'business logic' here. I really mean separating presentation and presentation data.

Since the logic inside of JSX is just JavaScript encapsulated in braces, you're basically saying that Vue's angular like attributes are better than just simple javascript syntax?

I don't understand how

    <ul>	
        <li v-for="num in listItems">{{num}}</li>
    </ul>

is less readable than

    <ul>
        {listItems.map((num, i) => <li key={i}>{num}</li>)}
    </ul>

Both are pretty readable, but the latter is essentially normal javascript, with the idea that you can return dom elements in it. The only thing that a javascript developer with zero jsx experience needs to know is that you can express dom elements within your javascript and treat them exactly like functions that return that element (which is what they are).

What someone has to know to parse your vue example is the exact syntax for for loops in vue, evidently the syntax in this example is quite simple but what if they want to perform extra logic in that loop to modify which elements to show? In the react example all they have to do is know javascript.... in Vue they have to go look up how to do that in Vue.

How is that more readable? Furthermore, does that break at runtime if listItem is undefined or you typo'd the second num? JSX would catch it as a syntax error.

Do you need the whole text of an error or answer "yes" will satisfy you ? :)

Yeah, runtime errors are bad. I don't know why you'd want to inject a string-based language inside JS.

I guess it's taste, but that's far less readable than the JSX with `.map` example to me. JSX is easier to use and read because you just use the JS constructs that you already know rather than a whole new DSL.

GP formatted it wrong, you could write the JSX example like this:

  return (
    <ul>
      {numbers.map((num, i) => (
        <li key={i}>
          {num}
        </li>
      ))}
    </ul>
  )

Which with syntax highlighting is, imo, as readable as any piece of code.

The advantage is that it is statically checkable with a linter, so you would get a compile-time error if you misspell the HTML tag, a variable or anything else.

If you use something Typescript, the compiler will even check the props given to components (and if you use VS Code, you'll get auto-completion for variables, methods, props and anything statically checkable). You can even apply inheritance to components for dynamic component switching.

I briefly used Vue before switching completely to React (with Typescript, Webpack and Mobx) and it finally became enjoyable to write Javascript applications.

Yes, this much easier to read. Only `v-for` is a bit of a black box so you need to find it's implementation in the Vue code to find out what's exactly happening