The perceived upfront cost is lower with Vue. You can just put it on the page and voila, you have observables, computed properties, templates, everything. No webpack, no transpiling, no modules, no npm.
This is also how angular got popular. The tutorial said: Just add this one JS to the page and start making SPAs! Here is a 10 line example with everything in it explained, and it works!
Same with mongodb - their 10 step interactive tutorial website was extremely convincing
Not many people know you can get started the same with react by putting react, mobx and mobx-react on the page https://jsfiddle.net/ugh2xhfg/. Thats because its not advertised. You will still need babel / compilation though. JSX is still a major barrier to entry.
There is no easier way to make a project become popular than to offer an unrealistic-for-production getting started page that will get you rolling by doing almost nothing!
> You can just put it on the page and voila, you have observables, computed properties, templates, everything. No webpack, no transpiling, no modules, no npm.
This is a false dichotomy. React is a fully-featured, standalone library and functionally equivalent to Vue if all you include is react.min.js. You don't need webpack or npm, you don't need Redux or MobX. This attitude stems from people learning React from create-react-app (which is geared towards a fully-featured, multi-developer, production-ready application) without doing FB's TodoMVC or even reading the React docs.
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 :)
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).
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.
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.
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.
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 :)
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 :)
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.
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
I started using vue because of the webpack integration and the wonderful single file html/es6/css components. Maybe I'm in the minority? It takes a while (and some guessing) to get it all set up, but it's incredibly productive afterwards (vue-router is a must).
Vue is an alternative for those who did not buy a ticket for the npm/node.js circus but have previous HTML/JS experience.
With vue.js you can write the good old HTML you are used to and enrich it with vue's magic, just like you could do with the original Angular. Anyone who comes from a jQuery or angular 1 background will be able to immediately pick it up. The only thing you will be missing are single file components.
Can you do proper react without studying a node.js Package manager, bundler, compiler, JSX?
One example why vue.js is easy and react is hard I just found: Google "vue two way binding input" and "react two way input binding". React's solution reads like a bad joke.
Uh... what solution, and in what way? React doesn't use "two-way binding", at least not in the sense that other frameworks do.
If you're talking about the idea of "controlled inputs", it fits with the rest of the React philosophy. Driving input values from state keeps the data flow predictable, and makes it easier to implement things like validation.
I've got a number of articles on React form management in my React/Redux links list ([0]). In particular, Gosha Arinich's article on the basics of controlled inputs is excellent ([1]), as is Loren Stewart's article ([2]).
Three unofficial links with each containing more content than the whole official vue.js guide on input binding. And we are talking about a very common feature a lot of users desire.
I guess I just don't fancy the "react philosophy", which is perfectly fine: I am happy we each got what we want.
My guess based on a few minutes of googling to explain the popularity of Vue: unhappy Angular 1 users (with Angular 2 being too different/complex/...?).
As I'm currently very happy with React I know too little about them, so correct me please.
This is just anecdotal, but I've never used Angular. I tried using React a few times but kept stopping since I didn't have enough time to get all the toolchain pieces installed and working together. Then I started hearing about vue so I tried learning it by dropping the vue.js file into the html page and it just worked.
We're sitting on several hundreds (yes, hundreds) "real world" apps and you can bet your butt that some of them do just that.
The more advanced ones use the whole tool chain. Simple ones are just a silly 1 liner script like that. Some don't use JSX at all and just straight up stick React on a page. It all works just peachy.
Superficially angular 1 and vue are very similar, so you might be on to something. But that's something great: There is a reason why angular 1 was widely adopted insanely fast. It's great to have a high performance replacement for it that is still under active development.
> Can you do proper react without studying a node.js Package manager, bundler, compiler, JSX?
Yes. React is just a view rendering library. All those tools are just to make your life easier (including JSX) and don't have any inherent connection to React.
> Google "vue two way binding input" and "react two way input binding". React's solution reads like a bad joke."
Sure, but that's because "two way binding" isn't really Reactive. I guess it depends on what your past experience is, but as far as API surface area React and Vue seem to have similar complexity.
Is React without JSX really something anyone would use though? All the examples are in JSX. Do you have the same first class experience?
> isn't really Reactive.
The go to response of react users when confronted with "I want to do X, why can't I do X?". It might makes sense for you but it pushes a lot of developers away.
I use React without JSX. With CoffeeScript it the render function is nice an concise, and I can use all the regular goodies of a proper programming language.
Granted most of the components/UIs are simple, but it works.
I think it's possible, but at the moment the vue.js usage share is still FAR to small. One of my countries job search platform offers 89 jQuery jobs, 46 angular (1+2), 28 angular2, 28 for react. 1 (one) for vue. (To put this in perspective, 643 Java jobs).
I don't know React but, since I know Vue, I'm confident that I could pick up React fairly quickly.
The reason Vue was easier for me to learn is because it feels like regular JS + HTML, and single file components only strengthen that initial confidence when learning the framework.
Vue just feels relatively normal and was an easier transition for me into the SPA world. React feels like an entirely new thing, even though they are extremely similar at the core.
But the complexity is layered in my experience. You can get very far by reading the guide and changing the names in the DSL to make your app/dashboard/etc and then ship that same day, without really learning any new concepts. Of course when you have to do something new or make a maintainable app you still have your reading ahead of you, but the 0-1 I got my app to do what it needs is really easy-going (again, in my experience for my limited use cases)
Vue is definitely much more approachable. I did not have this experience when using Angular not long ago.
To each their own, but I find the Vue API small and simple enough for me to keep it all in my head at once. Reasoning about things has become it a lot easier because of this.
in short, you write way less lines of code in vue, as opposed to react. its a pretty liberating feeling especially coming from monolithic angular and react code bases. this looks to me like the result of what happens when someone tries to create simple easy to use frameworks as their core philosophy.
How so? Vue actually has a lot to it -- lots of template directives, computed properties, directives, etc.