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.