Hacker News Reader

It's perfectly possible to refer to the `item` in the loop template:

    <li v-for="item in items" :title="item.hint"> {{ item.message }} </li>

I really don't have a problem thinking of them as templates. In a sense that's all we can do anyway with dynamic lists— I don't know how React works but it seems disadvantageous to be forced to run the loop again rather than be able to do a diff & DOM insert/splice behind the scenes.

My only real complaint is that the HTML attribute gets lost a little too easily. I could probably hack up some syntax highlighting augmentations to fix that, but it doesn't really bother me enough.

For what it's worth, JSX is supported in Vue as well, although I've found it's not really my thing compared to Vue templates.

Agreed completely. My favorite example is the `slot` directive which doesn't exist in React because the pattern comes for free.

To take the example from the Vue docs:

    // Component with a slot    
    <ul>
      <li v-for="todo in filteredTodos" v-bind:key="todo.id">
        <slot name="todo" v-bind:todo="todo">
          {{ todo.text }}
        </slot>
      </li>
    </ul>

    // Consuming component 
    <todo-list v-bind:todos="todos">
      <template v-slot:todo="{ todo }">
        <span v-if="todo.isComplete">x</span>
        {{ todo.text }}
      </template>
    </todo-list>

This can be rewritten in React with much simpler, cleaner code:

    // Component with a "slot"    
    <ul>
      {filteredTodos.map(todo => props.renderTodo ? props.renderTodo(todo) : todo.text)}
    </ul>

    // Consuming component 
    <TodoList todos={todos} renderTodo={todo =>
      `${todo.isComplete ? "x " : ""}${todo.text}`
    }/>

Simplicity is key. In the React version you don't have to worry about the `slot` syntax, build a mental model of how Vue treats it, or risk running into the limitations of the feature.

I'm not really sure how can you say that the React code is simpler or cleaner? Where do props come from? Where's the span for x? <li>'s are generated by magic?

I just don't like mixing html and js like that, maybe that's why it also seems messy to me.

The vue example also isn't the greatest, some cruft could be removed using default slot and shorter syntax.

Both Vue and React have props. The above code is a snippet; I used the same format as the Vue documentation (which I agree is a little confusing).

> Where's the span for x?

I assumed Vue was only using the span for v-if, in React we don't need that extra node.

> <li>'s are generated by magic?

Whoops -- an omission on my part. They should be wrapping the inside of the mapping function.

> I just don't like mixing html and js like that, maybe that's why it also seems messy to me.

But this is where the magic is. It's exactly why React didn't need to invent a concept for "slots". I admit it's vaguely unfamiliar at first but if it increases both the power and simplicity of your template it's a no-brainer.

gotta say, the vue example looks simpler and cleaner....also I notice you seem to be using the most verbose syntax for vue.

I completely disagree on first note, mostly because it's almost all JavaScript. There's very little "React" there.

On the second note it's copy-pasted code from the official Vue docs.

the best way to describe a UI is in javascript? huh... I wonder why people keep creating markup style languages to abstract away from programming languages for UIs? Basically if you are describing your UI in javascript, maybe that's not a good thing.

I don't really understand what you're talking about. For building a dynamic UI you need JavaScript (or another programming language). Both React and Vue use JavaScript to build their dynamic views. If you're not building a dynamic UI then you don't need either tool.

In react that's mostly true, in Vue (and things like WPF) there's a two layers essentially, markup to create bindings to reactive data, and code to define the reactive data ( though vue does let you blur the lines)

> markup to create bindings to reactive data

Right, and my argument is building this in JavaScript directly (rather than a HTML-ish/JavaScript-ish template language that gets converted into JavaScript) is a better model.

@ng12 right, you made a claim, I'm just saying, your claim seems unconvincing, and the example you gave doesn't seem to make for good evidence of your claim.

You're not making it clear why it's unconvincing. Let me summarize my post: Vue had to fundamentally introduce a new concept (which developers, myself included, find confusing [1]) to solve a problem you can easily solve in React without any additional APIs. React does this very much by design [2] and it's a huge part of the reason why I like it more than Vue.

1. https://vuejsdevelopers.com/2017/10/02/vue-js-scoped-slots/ 2. https://2014.jsconf.eu/speakers/sebastian-markbage-minimal-a...

This only makes sense for people who learned to program using React and only ever programmed in it. Not saying that's your case.

Vue.js uses templates, and the idea of slots already existed in other template languages for years. Angular, ERB/Rails, Razor, Django, Handlebars, Jinja, WPF, even some wikis: all those have the same concept, maybe implemented diferently.

On the other hand, React uses JSX, which is novel and wasn't really used anywhere else before. JSX also has the disadvantage of requiring a very complex toolchain (Babel and Webpack etc), something that Vue.js doesn't require.

If all the other frameworks jumped off a bridge, would yours jump too? :)

The real win here, even if you're familiar with other template solutions, is that you never have to ask the question "How do I do X in template solution Y?". React's JSX "templates" can be fully described in a single sentence: write some (X)HTML and use curly brackets to insert a JavaScript statement that evaluates to a primitive. There are no other concepts to learn provided you know JS and HTML -- and having spent lots of time introducing React to developers of various levels of front-end experience that's something I've come to really appreciate.

> If all the other frameworks jumped off a bridge, would yours jump too? :)

That's moving the goalposts. Your point was that Vue invented a new concept and that was a negative. I'm just mentioning how it wasn't an invention at all, it was already a popular concept present in multiple other systems. For people used to templating languages the concept of a slot is not confusing, maybe you just weren't familiar with it?

And it is false to say that JSX doesn't introduce new concepts and rules. The way JS and HTML interact inside JSX is not intuitive at all, and you can't use a lot of JS constructs inside JS, such as `for` loops and `ifs`. Of course there are other ways to solve it, but it's far from intuitive (and the fact that Babel returns "Unexpected token" when you do it doesn't help). For what is worth, passing components inside props in React is also not intuitive, unless someone shows you or tell you it's possible. When you do a few React tutorials you pick it, of course, and that's exactly the same for Vue.js.

Maybe you just find React easier because you learned it first? Maybe do a few tutorial lessons before judging it? Just because something is different or not familiar to you doesn't mean it's worse or is difficult.

Both frameworks are great, there's no need to pit one against each other.

You're getting into semantics. I don't mean they "invented" a concept nobody had done before -- I mean they had to sit down and build a new API in Vue (and write-up a very long documentation page) to solve a common problem. React, by design, avoids adding to the mental load for the developer by minimizing the amount of concepts they need to learn. I highly recommend this talk, he explains it better than I ever could: https://2014.jsconf.eu/speakers/sebastian-markbage-minimal-a...

> The way JS and HTML interact inside JSX is not intuitive at all, and you can't use a lot of JS constructs inside JS, such as `for` loops and `ifs`

You didn't read my one sentence definition. It has to be a statement that evaluates to a primitive. Obviously putting a for loop doesn't work there -- how could it? If you find yourself faced with that desire the obvious solution is to call a function that does whatever `for` and `if` statements you want and returns a value.

> Maybe you just find React easier because you learned it first? Maybe do a few tutorial lessons before judging it? Just because something is different or not familiar to you doesn't mean it's worse or is difficult.

I think it says a lot about your argument that you have to keep questioning my credentials and experience. I've been doing web development for a long time, React is closer to the twentieth framework I've used than the first. It's a big part of my job to build infrastructure for web development and teach the fundamentals to developers who are primarily backend engineers. I've had stellar success with React -- both for the "power users" and those with minimal web development expertise -- and my argument here is attempting to explain why I've had success with React where other frameworks have been struggled.

I completely disagree with the claim that JSX avoids that mental load.

You say "obviously putting a for loop doesn't work there" but it's nowhere near obvious. Loops in JSX are not obvious. Ternary conditionals are not obvious. HOCs and component slots are not obvious.

Only if you dive deep into how JSX works and how exactly it compiles to JS you're able to develop some intuition and figure those things out by yourself, but before you do, you have to do like every other framework (including Vue.js) and learn from the documentation and from examples.

I also like React and JSX, but I think you are biased towards some piece of tech just because you're more familiar with it.

> but I think you are biased towards some piece of tech just because you're more familiar with it.

Or because I spent more than half my career fuddling with sub-optimal technologies (up to and including Angular and Vue) and React had good answers for most of my complaints.

> Loops in JSX are not obvious.

Because loops don't exist in JSX. It is obvious, because it's not clear how you would even write one. Maybe someone might naively try something like this:

    const Todo = props => {
      return (<ul>
        {for (todo in props.todos) {
          <li>{todo}</li>
        }}
      </ul>)
    }

And get a perfectly reasonable JavaScript error: expression expected. This is just an orphaned loop, like you tried to put a loop in an argument to a function. From there it's an easy step (or a quick stack overflow) to figure out that you need to use the loop to build your array before inserting it into the JSX. Once you've seen this pattern, ternaries and "slot" components become obvious.

I can vouch for all of this being very easy to learn -- I'm constantly impressed by how quickly my students pick up "advanced" React concepts. Anecdotal evidence, sure, but it makes my life easy that I can explain the entire React+JSX API in 20 minutes and under a dozen slides.

Anyways, I like Vue. I think it has some great ideas -- but I wouldn't use it without JSX and at that point I might as well use React. It's my conviction that templates are misery and I'll champion any technology that gets us away from them.

> And get a perfectly reasonable JavaScript error: expression expected

Actually the error in CRA/Webpack/Parcel/Codesandbox/Babeljs.io is "Parsing error: Unexpected token", which is hardly intuitive and not all that reasonable.

> From there it's an easy step (or a quick stack overflow) to figure out that you need to use the loop to build your array before inserting it into the JSX

Maybe v-for wouldn't be "confusing" to you if you had the same attitude towards Vue. And maybe if you were less biased (as you admit you are against templates) and less extremist you'd see that students are quick to pick up concepts that you find confusing in Vue.js too.

Ah, that's the TypeScript variant of the error that I posted. Same meaning.

Again, my opinions are formed from doing this for a living, and honestly I've spent much more time in my career working with templates than I have with JSX. I've built non-trivial applicatons with PHP, RoR, JSP, Django, Mustache/Handlebars, Angular, Vue, yada, yada, yada. This is coming from an informed opinion, not thoughtless favoritism. Not sure what else I can say to you.

Is that MVVM or like Razor in asp.net core?

> What happens if I wanted to conditionally include/not-include an <li> for the list of items?

Depending on the use-case, I wouldn't want to put the conditional in the template.

Instead, I'd filter the array of `items`. Maybe using a computed property `filteredItems`.

The idea being, you shouldn't be putting Too Much Logic within the template.

Idk though, I started off in Vue and am very much enjoying it; I haven't spent a lot of time dabbling with React yet

Another way of rendering lists is like this:

    <ul id="example-1">
      <template v-for="item in items">
        <li>{{ item.message }}</li>
      </template>
    </ul>

Interesting. I was taking the example straight from their docs: https://vuejs.org/v2/guide/list.html

What you have here does fix the 1:1 issue, but introduces an extra layer of abstraction that still feels unnecessary/less straight-forward compared to the React version.

This is the kind of low-down I look for on these frameworks. It can be difficult to get insight from people who've been deep into a framework because they seem to get emotionally attached to their favorite. They ALL start from some well thought out paradigm, and can do what they were designed to do really well. How difficult is it when you start hitting those edge-cases?

I think OP took a look at Vue but stopped at a very superficial level. Vue’s Getting Started guide mentions how to handle both cases OP complaints about.

If you want to display only some items of an array, it is recommended to compute a new array that only includes the items you want to display[1]. A less performant way is to put a v-if into your v-for loop[2].

If you have a v-for loop `item in items` you can access `item` in any attribute. See [3] for an example.

[1] https://vuejs.org/v2/guide/list.html#Displaying-Filtered-Sor...

[2] https://vuejs.org/v2/guide/list.html#v-for-with-v-if

[3] https://vuejs.org/v2/guide/list.html#v-for-with-a-Component

Thanks for the reply. My experience with things like this (idiosyncratic, hard to discover syntax and scoping rules) makes my spidey senses tingle when I start hearing about how “clean” something is.

As you say, rendering a list shouldn’t be where the problems start.