Awesome until you look around and notice you’ve fallen into a pit of despair (tech debt) and have no ecosystem to leverage your way out of it or people you can hire that want anything to do with it :)
There needs to be concerns beyond pure speed and package size to dictate tools. Sometimes real world practical constraints must be considered
> you’ve fallen into a pit of despair (tech debt) and have no ecosystem to leverage your way out of it or people you can hire that want anything to do with it
It sounds like you're saying that the way out of tech debt is to install more 3rd-party packages and/or hire more people, I hope you meant something else.
I use and recommend React at work because of the hiring thing, but for my own personal projects I stick with Mithril. With JSX it's not hard to switch back and forth between the two, at least with TypeScript there to tell me when I accidentally use HTML in my React JSX, e.g. the class attribute when React wants the className property. (With Mithril you use attributes that map exactly to HTML attributes)
I’m saying check Mithril npm packages vs react/vue packages, contributed by the people who wanted to work with each framework. Some ecosystems have more work to pull from, more people active and experienced, and more established patterns & tools.
I've been very happy recently with using the Vue.js ecosystem with the standalone vue.js and a few others directly <script>'ed from my applications. Usually vue.js, vuex.js, vue-resource.js and maybe vue-router.js are all dependencies I'll have to add. This avoids the npm circus with the (from my point of view acceptable) downside of, for example, not having single file components. The advantage is a minimal set of dependencies of ~70kb compressed JS added in total and a community where most of the question I had are answered somewhere.
Eh, I wouldn't qualify technical debt as having less mind share. This is like saying code is worse because it's more concise and has less moving parts.
There needs to be concerns beyond pure speed and package size to dictate tools. Sometimes real world practical constraints must be considered