Changes that break backwards compatibility are reflected across all three at the same time, and the correct versions are installed by vue-cli. I had several starts with react, react-router, and redux, and on almost every occasion something from my last attempt was broken because the api had changed, and the documentation changed with it (in the span of 3-4 months). That lead to several WTF moments. IIRC there was a period where react-router made some breaking changes from v2 to v3, and then less than a year later made more breaking changes for v4.
Vue is also a lot simpler to drop into an existing application. The .vue single-file component is very approachable, albeit a bit magic but about as magic as JSX. You can add a vue-loader for sass/less/etc. and simply specify lang="less" in these as well.
Vuex was a little easier for me to grok, although I had the advantage of trying out redux first. It has the advantage again of sharing documentation with the rest of the project.
Also, because react has worked for big companies as you mentioned, does not mean vue couldn't work for them as well. React gained a lot of momentum early among western programmers. Vue first gained traction in Asia - Evan You, the creator of vue, is from there. Also you might remember the massive amount of confusion for early React adopters regarding how to manage state. People liked react, but it only really had the view part ready out of the gate. Facebook's explanation of what the early-best-practice flux model entailed was vague, and there were several slightly different implementations.
I remember working on Angular 1 projects, where literally everything from loops to http calls was mandated by the framework. Then everything suddenly became legacy. Angular was going to be completely rewritten, and everything I had learned was going to be tossed away. I still, to this day, have to work with projects that are Angular 1 code rot hell.
I think that's probably why I have never had the problem's you have had, because I never wanted to use React Router or Redux. Those pieces of functionality were easy to implement on my own. (Redux itself is incredibly small)
Personally, I think it's silly to use Vue. Angular had serious deficiencies and project mismanagement, and React was a real solution to those problems. I mostly hear either minor grievances from the Vue crowd, or no response at all as to why they switched (hype train most likely).
I also don't think Flux was vague, it just lacked an implementation. Again, there just seems to be a big fear in the JS community about writing code instead of pulling in a framework. React itself is just reactive functional programming. The sell of not writing it yourself is that you get to work with a nicer API while the React team improves the backend for you (a la Fiber).
You can't really have it both ways though: if you're going to say React doesn't do all those things then you have to accept that people who want something more streamlined and comprehensive should legitimately look somewhere else, and React is only for people who want to spend the time assembling their own solution (for some acknowledged benefits). Vue has taken the more comprehensive approach while still being pretty flexible, and therefore suits a slightly different (but I would argue, broader) set of people.
Ok, but people learning React - with no guidance from the library or its maintainers, as you said it's only the view - are going to search for "react how to route" or the like. They end up using things like react-router, and some of them run into problems like I did. You did ask originally what makes one easier to learn than the other.
> to give people to freedom of choice to choose or omit other libraries or frameworks. [...] Those pieces of functionality were easy to implement on my own.
And I listed some problems that I had using those other frameworks which were recommended to me. "Just do it yourself" isn't exactly helpful.
> (Redux itself is incredibly small)
Ok, but it has had some API churn as well - EDIT: I was wrong about this. See replies.
There's definitely boilerplate that goes along with it. There are libraries that deal with that to an extent, but there are many. Which one does someone learning choose?
> I remember working on Angular 1 projects...
What's that got to do with Vue? Vue isn't Angular.
> Personally, I think it's silly to use Vue. I mostly hear either minor grievances from the Vue crowd
I gave you my examples. You seem to compare only the view layer functionality. I'm examining the ecosystem and preexisting examples of how to implement functionality, which is going to be important for someone new to the library. Of course you can write this yourself, but for people trying to learn React, only having the view layer makes it more difficult to figure out how to "implement it on your own".
> I also don't think Flux was vague, it just lacked an implementation.
Not having any public implementation is pretty vague!
> There just seems to be a big fear in the JS community about writing code instead of pulling in a framework
Well, again, my response was from the perspective of someone learning React and how one might architect a SPA using it. As stated, there was no official flux implementation in the beginning, just a diagram from Facebook and some hand-waving documentation. Vue has official and router library and state management library which are linked to from the official documentation.
> React itself is just reactive functional programming. The sell of not writing it yourself is that you get to work with a nicer API while the React team improves the backend for you (a la Fiber).
You can apply this your own argument. React is just reactive functional programming. Why just pull in a view library when you can just render using functions? Why not write it yourself, if you're writing everything else yourself? Are you afraid to? Why include a 240kb library to render functional components?
What do you get out of using React over Vue, which also uses the virtual DOM and has functional components?
Uh... what API churn? The Redux store API hasn't changed meaningfully since about a month after its 1.0 release. 3.0 came out around September 2015, and it's been the same since.
React-Redux has stayed API-consistent too, even though we rewrote the internals for 5.0.
Since then, the most meaningful API change was 3.1.0, which redid the `createStore` signature to allow passing an enhancer as an argument (as opposed to the original more FP-style approach).
Vue is also a simple view library.
You keep bringing up Angular, as if Vue has something to do with it. Vue is so much closer to React than to Angular.
> You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.
Sorry, but that sounds a lot like rationalization and wishful thinking, written purely to make React look good and anything else look bad.
Vue also has backers that contribute financially, a large community using it and sustained development. The fact that it isn't as big as React doesn't make it unworthy of existing or unable to provide the same technical benefits as React.
1. Js doesn’t support immutable data structures so trying to return a deeply nested model using spread and other things was ugly. The answer seems to be “flatten your data”. I didn’t have to flatten my model with vuex. Vuex uses mutations when I can keep a flat model of observable but also keep my pristine model that I can send back over the wire with no changes . I suspect mobx may do the same sort of thing for vue. I feel like the react pattern would work better with a language like clojurescript that actually has immutable data structures.
2. Prefer html to Jsx although vue does support jsx. Admittedly this is just a preference thing.
3. Less boilerplate. I felt like I was writing more code that didn’t really do anything useful in react/redux. Vue seemed to have the smallest ceremony to code ratio.
4. Vuetify seemed a lot easier to use and was more polished than the react counterparts. I know it’s just a widget library but I found it fantastic and the docs were great. Vue slots are a great idea
5. Documentation . Vue has second to none documentation and this is important when you are starting out
I build a medium sized app in vue and was astounded that I literally did not run into one issue. That has never happened to me in 30 years. Kudos to that team.
6. React router was on its 4th rewrite. I can’t deal with constant breaking changes
7. Router and vuex felt more cohesive and integrated into vue
Whatever you choose please do support these guys on patreon!
I hear this line a lot, and it reminds me of Warren Buffett's line about finding out who's swimming naked when the tide goes out. He's referring to unprofitable companies that get exposed during economic recessions, when their stock prices are no longer boosted by generalized positive sentiment (I'm oversimplifying).
In this context, I think frameworks get exposed when big company support gets withdrawn. Angular didn't always look like an abandoned beached whale. Initially, having the backing of Google made it look like a de facto obvious choice. But when support from a large backer wanes, it quickly accelerates the demise of a framework as what the halo effect previously presented as well-considered design choices are suddenly recast as clear mistakes in hindsight.
This might never happen with React. But if it does, it will be swift and loom with unmistakable signs in the rearview mirror.
The JS ecosystem really has a problem with bloat in my opinion and Vue trumps React in the regard (react eject anyone?).
My cofounder suggested I check out vue for the rewrite of our legacy project, and I was able to onramp SO easily. I can easily hand off components to other team members to write, and it rarely broke stuff in the rest of the project. On the whole, vue feels a bit less powerful but a LOT simpler to wrap your head around while subscribing to the reactive UI paradigm.
For example, JSX is an abstraction level I'd like to use. It requires an npm install to set up to contribute to production code. It has already crossed the threshold of an easy on-ramp for say, an intern -- because if this involves a first-time npm set-up on their machine, there goes the rest of the week.
With Vue to start using another feature/abstraction layer, you never have to do additional setup (your html file includes the vuejs script already), you just read the syntax docs and get going.
Additionally, React (and redux even more, yes) involves much more boilerplate than Vue does for every new feature you want to use, which is often more verbose/obtuse and hard to parse for a junior web developer.
Sorry, in your last post you specifically mentioned only terms that apply to Redux. React has no concept of actions, reducers, etc.
If you read my top comment I specifically talk about React’s function component, which is the least verbose way to describe an interface across any framework. Unless you can think of something easier than (props) => <h1>{props.name}</h1>
Honestly you just need new interns.
I'm curious whether Facebook actually have any endpoints where exceedingly fast rendering is necessary because it'd be the bottleneck. Facebook tends to be really slow for me but I figure that's down to it being really slow fetching data.