Vue.js: the good, the meh, and the ugly

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.

The quality of answers were so low I found myself longing for the days of expertsexchange.com.

Why did laracast get so popular for Vue? What was wrong with Stack Overflow?

However, some of the things that have been traded are default configuration that represents typical use, standardisation across the ecosystem, and brevity. I think that for a lot of use cases, these tradeoffs make React-Redux harder to use, and that as a whole they make it easier to cause significant architectural problems for a newer or less technical user.

> If you _really_ want to, there's nothing stopping you from importing the store globally

What I've taken to doing is exporting a dispatch function that calls the store's dispatch, not the store. I think this better captures the intention behind Flux than a higher-order component, without much cost, since dynamically swapping between stores doesn't seem common.

> ...one of the key design points of Redux was to allow users to choose which approach they want to use to handle async logic...

This power and choice, while allowing a lot of freedom, comes at the cost of a fragmented ecosystem. The Redux documentation page for async actions lists six different packages that can help.

> the "dispatching an action === calling a function" comparison can be true, but only if you're using Redux with a limited mental approach and treating actions like "setters"

I may not have explained that very well. Actions themselves make perfect sense from the perspective of a reducer, and clearly they must be dispatched, but they're a state management detail that the UI doesn't need to know about. Something similar to redux-action could be the default.

I suppose my core problem with Redux/React-Redux is that I don't understand why a typical component in a typical app doesn't look like

  import { connect } from 'redux'
  import { deleteFoo } from '../actions'
  
  const FooList = ({ foos }) => {
    return foos.map(foo =>  deleteFoo(foo.id)}>Delete {foo.name})
  }
  
  export default connect(state => ({ foos: state.foos }))(FooList)

> What I've taken to doing is exporting a dispatch function that calls the store's dispatch, not the store.

Not sure I follow that train of thought - could you point to an example?

> Actions themselves make perfect sense from the perspective of a reducer, and clearly they must be dispatched, but they're a state management detail that the UI doesn't need to know about. Something similar to redux-action could be the default.

This is why we recommend use of action creators, so that a component is just calling `this.props.doSomething()` without it "knowing" that a Redux action is actually being dispatched.

Per your snippet there at the end:

- `redux` and `react-redux` are deliberately separate packages, because the Redux core is 100% vanilla JS, and independent from React (in the same way that `react` and `react-dom` are separate packages - the core React logic is independent of the platform-specific reconcilers). So, `import {connect} from "redux"` wouldn't be appropriate.

- The use of `deleteFoo()` that way assumes that it's pre-bound to a specific store instance, which limits the reusability of your logic, and also makes it a lot harder to test. `connect` abstracts away the question of "which store instance am I interacting with?", so that your components and logic are more testable and reusable.

> Something similar to redux-action could be the default.

For what it's worth, earlier this year I threw together a small `redux-starter-kit` package: https://github.com/markerikson/redux-starter-kit . The goal behind it is to simplify some of the most common pain points around Redux: store setup (including thunks and devtools), writing immutable updates in reducers, and having to install multiple packages out of the box. The biggest thing I know it's still missing at this point is indeed something akin to `redux-actions` - see my notes at https://github.com/markerikson/redux-starter-kit/issues/17 .

I haven't had time to push it forward further, but I would seriously like to get some more eyes on it, see if there's any other use cases we should be covering, and then make it an official Redux-branded package and update our docs to recommend that people use it.