Here is an example of that code implemented in Vue.

https://codepen.io/Kradek/pen/JyLPaL?editors=1010

I really haven't run into anything I could do in React that I couldn't do in Vue. What I mainly miss in Vue is react-native.

Great, here are my thoughts on it

1. Render methods make vue basically the same as React plus MobX, right? (and afaik you can use JSX too)

2. The spinner component was registered in the global scope. Will normal build tools know about the file and properly include it, or an import will need to be placed somewhere for that to work? What happens if another module registers a "spinner" component? ES6 and CommonJS modules have already solved this elegantly, and I believe its a must for larger scale applications that may consist of multiple complex modules

3. I see many wheels being reinvented, and as a non-vue user I have no idea what they mean. For example, does `<template scope="data">` name the first argument passed to the function? Is `default` the name of the first unnamed template? And this page is utterly baffling: https://vuejs.org/v2/guide/components.html#Scoped-Slots as I cannot figure out which thing is the template that is being passed arguments and which is doing the passing (and how).

edit: re (3) I finally got it, a `template`'s `scope` gives the props passed to a `slot` a name.

It seems to me that templates look like less learning initially, but they end up being more...

1. The MobX-like functionality is moreso simply a native feature of Vue. All data values are converted into observed values. A render is triggered by changes to data. I believe Evan himself basically said React + MobX = Vue. Using a render function was just a choice. It could just as easily have been written with a template.

2. Again, this was basically just a choice for the example. The spinner could be defined in a module and imported/registered locally. Codepen/JSFiddle just isn't the greatest place for that kind of example.

3. Scoped slots are a way for a component to expose internal data to elements contained in a slot (content thats contained within the component but defined by it's parent). I agree, its initially one of the more confusing concepts in Vue.

Ok I think I figured out how to use a template with a slot in the spinner component:

    <div>
    <img v-if="this.status == 'pending'" 
         src="https://media.giphy.com/media/10kTz4r3ishQwU/giphy.gif" />
    <slot v-if="this.status == 'success'" :list="this.data"></slot>
    <div v-if="this.status == 'error'">{{this.error}}</div>
    </div>

Then in the template the option line becomes

    <option v-for="option in data.list" :value="option">{{option}}</option>

Not too bad. Guess I'll have to come up with a new example of what Vue templates can't do now!

You nailed it :) You could also destructure the passed properties in the scoped slot (scope="{list}") so you could just use "option in list".

I wonder if the JS snippets in those attributes is syntax checked at build time or run time.

Vue templates are compiled into render functions. They are checked when the template is compiled. If you are using a build process, then that would be at build time.

Is there any editor support for that? One of the things I like about React + TypeScript is that the JSX is syntax-checked and type-checked in my editor as I type. My understanding is that this is possible because TS has built-in support for JSX.

Not yet as far as I know.

    or introduce new and weird concepts to replace things that
    are easy, familiar and often better designed in the host
    language.

Oddly, that's exactly how I feel about the "{condition_expression && template_evaluation}" idiom in JSX.

Personally I prefer the ternary operator in those cases, however I think do expressions will fix most of the if/else awkward stuff: https://babeljs.io/docs/plugins/transform-do-expressions/

I'll use a ternary if I want something in the "else" case, but otherwise the `&&` / `||` approach is more readable to me (there's more to read in a ternary to figure out that there's nothing happening in the else case, whereas it's obvious with the boolean approach without reading further).

Can that actually help react look better here? I'm currently imagining:

  { do {
    if (condition_expression) {
      template_evaluation
    }
  }}

For a single expression some of it can be omitted:

  { do { if (condition_expression) template_evaluation }}

But I gues thats not really better.

I'm hoping jsx will eventually default to `do` expressions though, and then it becomes

  { if (conditional_expression) template_evaluation }

Hmmm, I really like the terseness and obviousness of that approach, I use it all the time :)

I have sometimes been caught out by doing `{somearray.length && thing}` though, which leaves `0` hanging out there in the false case...