I don't think you can ignore the relative less amount of pain associated with Vue.js over React.js.

It's just easier to get started with Vue.js and I'm just tired of the constant marketing campaign from Facebook...guess what 99.9% of companies out there aren't facebook or google.

The relative ease to get into Vue.js and it's fast growing popularity are signs that it's hitting the right pain points with developers who don't work at Facebook.

The thing is, in any real project where you need a front-end framework, you will need modules very soon. And once you need modules, you need a bundler, which means you need a build process. While you are building, you might as well take advantage of neat ES.next / TypeScript features such as decorators, as well as maybe type-checking for JSX templates, and so on.

This is the reason why I always choose React.

(Well, that, and the huge existing ecosystem, and fact that components are first class in the template language e.g. you can pass a component as a parameter to a template and you can bring components into scope by importing them. But those are fairly advanced features)

> The thing is, in any real project where you need a front-end framework, you will need modules very soon.

Sure, and modules are good even if you didn't need data binding at all. But the data binding and the module system you use are orthogonal and CommonJS/npm is still larger than any other module system by 10x, maybe 100x, maybe more.

Right. CommonJS is great, I actually like it more than ES6 modules. But even with CommonJS you still need the bundler and the build step.

You can get data binding in React with MobX, which pretty much gets you on par with Vue: https://mobx.js.org/getting-started.html . If you don't like how anemic setState is, and don't like the boilerplate / straightjacket of Redux, MobX is the way to go.

Admittedly, React's simpler options are harder to find :)

> The thing is, in any real project where you need a front-end framework, you will need modules very soon.

Only if you go the SPA route.

No, only if you plan on writing any reusable components. Which is sort of the point of any framework.

Well, unless you plan on writing all your code in one file (likely painful), or using an async loader (either slow, or painful because of manually managing dependencies and load order).

We had reusable components long before SPAs, but each individual page is largely unique anyway.

Depends on what you see by "largely unique". Do you have a spinner while you wait for data to show up on each page? Then you might have a common spinner component.

Of course, you could also re-code the spinner every single time. Or you could use an existing library of components and then you don't have to deal with modules, only that library does.

Easily done by including the component server side, either in the master page (for common things that are used everywhere) or the page itself. SPA's do literally nothing to componentize sites/apps that we couldn't do before.

How about components that you need twice on the page? Are you going to just include them and their JS twice? Or perhaps build an elaborate server-side module system, one in which components required multiple times are only included once at the end of the page with a script.

And you have everyone of those with Vue too btw

Not really.

You don't have typescript's typechecking for templates.

You don't have higher-order components or first class components. Scoped slots are almost there, but not quite.

Also, "scoped slots" show that vue's simplicity is a bit of an illusion. There is a lot of reinventing the wheel happening underneath to get templates to the basic level of modularity / encapsulation / features of plain old JS.

It was similar with Angular. "Look how simple it is!" - yeah, until you actually need to build something serious with it... then you need to learn 3 times as much as React and all its tooling.

Here is an exercise: Write a spinner component in vue that renders either a spinner, an error message, or any other component (must be passed to the spinner component as a parameter) to which you can pass the data of the fulfilled promise.

Here is a react implementation:

https://jsfiddle.net/mm145xkj/

You just write a component where you pass two props: a promise to monitor, and a function that will take the data of the fulfulled promise and use it to render anything.

How do you do that in Vue? Is it simpler than the React implementation?

Nobody responded to you, so I took on your challenge :) I'm still pretty new to Vue, but after a while of fiddling I came to a pretty simple solution: https://jsfiddle.net/jsfiddle4ephi/6xLwgqxk/1/

IMO, this is more readable than React, especially if extracted to their own .vue components.

1. Upon a successful resolve, you can make it render props/data to a custom component.

2. You can put each of the component into their own vue files to make it super clean: https://vuejs.org/v2/guide/single-file-components.html

This was a fun challenge, thanks!

Nice try, but I expect that the template is contained within the app template (or really any other template), i.e. `<spinner promise=promise> <inner template parameterized on data here></spinner>`. I don't want to be passing raw html strings around.

I'm sure vue has some scoped slot template transclusion thing to solve it... actually scratch that, I'm not sure if the equivalent of plain old first class functions exist in its template language :)

I also forgot:

Its not just about raw HTML: this might need to be a totally custom template with data bindings to other data. Here is an example, the spinner's promise provides the data for a dropdown component which in turn is bound to a member of the parent component's data.

The challenge does need some more work to make it more realistic :)

Exactly. I could easily get into Vue. But not to React. Perhaps its my plain js affinity speaking.

> This is a false dichotomy.

No, React beginner tutorial implies learning JSX , then you need to compile JSX into JS. Vue.js does none of that. You just write Javascript and HTML. And yes, Vue.js also supports server-side rendering.

The argument is passing your source code through a REPL makes it significantly more difficult to learn? Learning JSX isn't any more difficult than learning Vue's template binding syntax.

You're completely ignoring the argument. React doesn't really tell you that you can just grab that file but even so you still need to get JSX processed.

It's all about the friction. Vue currently offers significantly less friction to jump into than React.

JS -> JSX is transpilation, not a REPL.

Yes, and the Babel REPL/CLI can do that transpilation.

One wouldn't normally use babel as a REPL. I don't think it even has one (asides from node's own REPL, which isn't normally part of using Babel). Have you ever interactively typed commands into Babel?

> React is ... functionally equivalent to Vue if all you include is react.min.js

Not really, you also need react-dom.min.js ;) But even then, Vue is sporting automatic reactive dependencies, computed properties, watchers, conditional class names, and other things without requiring a trip to some random NPM package. And it's still a smaller payload than react/react-dom

Right. You need inferno-compat as a drop-in replacement for react, as well as mobx for all the other vue features.

The payload for that would be similar to vue: 15KB min+gzip for mobx + 7kB for inferno-compat + 4kb for mobx-react = 26KB min+gzip. Latest vue is also 26KB min+gzip