I agree with the point that one of the biggest warts on Vue are the corners of the reactivity system (first point in the "Not so magic" section of the article")

I agree with the point that one of the biggest warts on Vue are the corners of the reactivity system (first point in the "Not so magic" section of the article") and how it can surprise you. IMO if Vue had reactivity like KnockoutJS did, it'd be perfect on that front. I disagreed with the "unclear architectural patterns" -- I've found just writing Vue components that function as Services to hold all that kind of logic more than adequate, and have never really needed to follow the Flux-ish/Vuex approach. 90% of the time all you're doing is making web requests and possibly displaying data or results to the user on the frontend... If you're clever, you're doing a little caching and figuring out when to perform remote fetches, or storing stuff in local/session storage. I think Model-Service-View frameworks are the (minimal) future, where you just pair a view library with a data management component (something like Backbone, if not Backbone itself). MVC was the dominant paradigm (angular 1 days), then MVVM made an appearance (knockoutjs), and now MV-? where the ? is some event-driven system or flux/vuex style system. I think abstracting to Services allows flexibility at the model-management layer -- if you want your services to send out events (and wire up your components to listen), then good. If you want them to have promised based interfaces, that's fine too.