[ilovecaching]

I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything. It's always been a library, not a framework, to give people to freedom of choice to choose or omit other libraries or frameworks.

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).

[zmmmmm]

> I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything.

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.

[ppseafield]

> I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything.

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?

[acemarke]

> Redux has had some API churn as well

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.

[ppseafield]

Ah, It seems I was very unlucky as I started learning it right before 3.0 and tried to pick it up after 3.0. Upgrading my previous project gave me strange errors, and the documentation had changed with it, leaving me to puzzle over what had happened.

[acemarke]

That must have been a pretty tight time window :) Per the releases page at https://github.com/reduxjs/redux/releases?after=v3.0.1 , you can see that 2.0 and 3.0 were only a couple weeks apart, and basically just tightened up the API around hot-swapping the root reducer.

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).