> But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all. > Is there a particular situation you are thinking of when you

> But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all. > Is there a particular situation you are thinking of when you say we are in need of said ecosystem? Here's a concrete, real-world example. I spent several months researching Vue and React for a large SPA migration from AngularJS at work. In order to migrate a single page, I had to write three compatibility libraries that already existed for React. This was for a simple page that pulled in data via an API and displayed it in a handful of tables. Another engineer did an audit of our third-party library use and needs, e.g. complicated "excel" like spreadsheet tables, and we simply couldn't find an existing Vue solution. That meant I would need to write my own compatibility libraries for at least another half-dozen complex libraries. There was an argument in favor of using Vue because we could get a lot of open-source exposure so I'll give it that. Plenty of low-hanging fruit for the open-source Vue developer. Perhaps Vue folks are only working on extremely small, basic, CRUD applications. The software I work on is not. > I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach React simply provides you components with a lifecycle. You are free to architect and compose those primitives however you see fit. Contrast with Vue, can you please reasonably explain the difference between a custom attribute vs. a component and when it would be appropriate to use one over the other? How is this simpler? How is this "keeping it simple?" This is only a single deviation between the two. Vue tells me it is "opinionated" but when I have to research, compare, and contrast it's own core features I have to ask how is this "opinionated." If I have to do all of this legwork how is it "Keeping it Simple, Stupid?"