I mean... no... the entire point of Redux is that it enforces immutability.
Make a mutation-first state library for sure, but don't pass it off under the guise of "Redux", or insinuate that reasoning about Redux at scale would be any more difficult than doing so with your own state library at the same scale.
Speaking as a multidisciplinary (but primarily JS) developer with React Native experience, there's no need to remove this kind of article as, if written properly, it can inform good choices. I feel articles like this one could be downvoted, given missing benchmark code samples and qualitative comparisons on the author's part. Some statements are plain incorrect:
"With react native, we have seen a big challenge to keep 3rd party libraries and APIs updated, as there’s nothing to keep track and notify developers on what packages/libraries/APIs requires updation."
- Ever heard of Yarn?
So, yeah. My 10¢.
Love this. But I noticed the Lodash dependency is pinned. Would it be possible to loosen it a little, to allow for flattened dependencies in frontend bundles?
Vue isn't strictly monolithic and is intended for the view layer, much like React. It can be sandwiched with Vuex, a Redux-like state library, for unidirectional data flow. By default, it uses a MobX-like approach to data binding (AFAIK MobX is influenced by Vue's default approach to binding, which is getter/setter based), and a pub/sub model for cross-component communication (not sure whether this has been retained in v2.x). It's seldom that we see React without either Redux or MobX, so making these tools/methodologies first-party makes sense.
Vue's drawcard, for me at least, is its tiny size. Last year, I built out a rather large app using Vue < 1.0, and found that the whole thing came in under the gzipped size of React alone (with no additional tools like Redux or React Router).