EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
Try mobx state tree for all the benefits that redux has without the pain.
Vuej seems nice enough (especially for migrating server side tech apps), but I'm still not digging the templating engine. I've seen the way you can use JSX in Vuej, and I don't like it.
The CSS styling for a component is handled much more cleanly than React does.
The lifecycle methods are named more sensibly.
You can add as little or as much Vue as you like, very easily, using no build system or going as far as to only use the build system.
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
In the same way Google pretty much decides web standards these days (unless most other implementors refuse to back a proposed standard; even then, Chrome can keep supporting something), Facebook could end up deciding standards. The former with the browser, the latter with code that runs in the browser.
Though Vue has more contributors now, that a single person could start and grow an open source project, with his own goals an opinions, shaping a community around certain principles, is something that appeals to me on philosophical and political grounds.
By the way, until recently, the recommended way to get started with React (unless you were using a bundler, hosting it yourself or using another CDN) was to load it from fb.me, a Facebook-owned domain.
What I meant: I believe big corporations like FB and Google do open source for a reason. A strategic reason. There are two that come to mind: (a) being able to push standards (like MS tried with IE). (b) usually these libraries are loaded from the respective companies’. It is possible that the loading data is then used to augment other data they have. In the end, both companies’ business models is based on data, only.
Compare that with vue.
You can even use JSX if you want.
Of course, the problem is not quite solved by not having a build step. It just means that things will bite you later, once you have enough components that just loading them one by one wont do. (at least not yet - we need smart HTTP/2 servers for that).
Then you add a simple build step in the form of bundling. This is a happy medium and most apps will survive very well with this sort of setup (a single bundle).
But another point might come where the single bundle is too large to be served in one piece. At that point you need code splitting. And now if you're using one of the custom framework module systems (which work by defining global named "injectables"), you might regret it, since code splitting bundlers rarely understand the dependencies between them. Not sure what the situation in Vue land is, but if you're using the asset pipeline you'll likely have to manage two sets of dependencies per file (your requires and your vue components) and then last time I checked, Sprokets does not support code splitting.
This entire situation is caused by two major problems with the web platform:
1. The ES6 module system is not yet available in browsers, and servers and browsers are not taking advantage of HTTP/2 push to ensure efficient module loading. You can create a service worker to support this browser-side (https://mariusgundersen.net/module-pusher/), but then there is Safari - and dammit, this stuff should be built in and commonplace everywhere!
2. You can't use the ES6 module system to modularise the rest of the assets like CSS and HTML. An ES6 module can't request for a CSS file, templates or other assets to get loaded via push. (Well actually it can via loader hooks I suppose, but there is the CSS modularity problem). There is another way to do this called HTML imports (which combined together with Shadow DOM finally gives CSS some modularity), but its a whole different thing form ES6 modules and its unclear how to make those work together. So to use that you kinda have to throw ES6 modules with the bathwater too.
3. IE11.
Someone on those standards bodies should get their act together and fix this dire situation. Until then, I'm excited about Parcel's way of handling this, with its async imports support making code splitting quite transparent. In general the ES6 module system has the best bundler support thus far, so JSX and css-in-JS (or at least css-modules) make sense to me for the foreseeable future.
p.s. One other reason why this isn't fixed is probably because the big companies that have the most say in standards bodies and browsers don't care. Preliminary research showed (can't find the link) that HTTP/2 push would have about 5-10% overhead over current optimal bundling and code splitting solutions, and these companies have their own developed infrastructure to optimise every last bit of performance - they can't afford 1% drop, let alone 5%. So there is no incentive to help the rest of the web.
Most of the js ecosystem fails miserably at a). And for b) the advantages of es6 and / or jsx aren't universally appreciated.
A good example of a build that IMO delivers both a) and b) is Elm. The build is simple (like compiling anything, but you can get all webpack complicated if you really want) and the syntax, static typing, and compile time errors add enormous value.
This is not a pro for me, I much prefer using the templates of Vue.js than JSX.