Comment by vec | Hacker News Reader

Comment by vec | Hacker News Reader

Parent Full thread

> Some of these directives ship with core, but some are third-party, so you have to remember which is which, and which your team has added.

Not to nitpick, but I think this might be the nut of our different reaction here. Some of our directive are core, and some are third-party. 99% of the time I don't have to know or care which is which. I just use them and they work and I don't have to think about how or why.

Perhaps this would be clearer with an example. Our API serves numerous types of copy as markdown strings. In our React code, embedding a markdown string (assumed to be in `this.state.copy`) into a div looked like this:

    <div dangerouslySetInnerHTML={{__html: md(this.state.copy)}} />

In Vue, it looks like this:

    <div v-md="copy" />

The first one is easier to statically analyze, but the second one is far easier for humans to read and to write. Vue allows me to abstract away all the details of how `copy` gets turned into HTML so that my templates can clearly express what I want them to do. The signal to noise ratio remains high, and if it starts to feel verbose or boilerplatey I have a large box of tools with which to fix it.

Static analysis aside, the first snippet using the React API is very much designed to be used sparingly. I feel It's a bit of an unfair comparison to take an escape hatch that's intentionally verbose and indicative of "dangerously using strings directly" and judge it based on its convenience...

Maybe you're hitting a pathological use-case because of the nature of your API. In which case you can always wrap it inside a single function and just do `<MyMarkdown text={bla} />`

I did choose a pathological case, partly because there's no way to write the `md` helper function in a way that react will just treat as always safe, other than wrapping it a component. But then components requires a single root element and unless I want it to always be a div I also have to pass in a tag name and this is rapidly ceasing to feel simple.

But it's not just contrived examples. Here's a list:

    <ul>
      {(this.state.items || []).map(item => (
        <li>{item}</li>
      ))}
    </ul>

vs

    <ul>
      <li v-for="item in items">{item}</li>
    </ul>

And here's a simple if/else

    let loginOrLogout
    if (this.isLoggedIn()) {
      loginOrLogout = <LogoutButton />
    } else {
      loginOrLogout = <LoginForm />
    }

    // snip

    <div>{loginOrLogout}</div>

vs

    <div>
      <logout-button v-if="isLoggedIn" />
      <login-form v-else />
    </div>

React is conceptually simple, but that often forces me to write complex code. Vue lets me keep the code I write (i.e. the only code I actually care about) simple.

If you haven't watched it before, I'd recommend "Simple Made Easy" by Rich Hickey. [0]

The reason I say that is because you say "conceptually simple" as if that's a bad thing. Maybe we have to agree to disagree, but in choosing a framework I would much, much rather go for the one that is conceptually simple (at the cost of some extra verbosity in certain cases) over one that is conceptually complex but covers up that complexity with a terse-but-incomplete API.

You're not going to understand the benefits of the Vue vs. React choice by looking at idealized code samples, which is all your comment is showing. You'll only know it once you get into the edge cases. For example for list iteration in Vue...

- ...how do you change that example to omit the last item?

- ...how do you change that example to render a different element for every other item?

- ...how do you render something different if there are no items?

That's what makes the JSX approach simple. Once you understand that you can use any Javascript expression you want, you don't need to learn further. All of those questions can be guesstimated by a newcomer.

But with Vue you have to learn each and every "directive" and "modifier", and consult the docs again each time you forget them.

[0]: https://www.infoq.com/presentations/Simple-Made-Easy

Reply on news.ycombinator.com