Interesting. Ultimately for me the size of a library/framework isn't really a great argument if the web app is javascript intensive, since my own code might be 5 or 6 times bigger than the framework itself.<p>The "legacy/debt" issue is more interesting matter. React and Angular are obviously big right now so most shops go with these.<p>But I explored the best ways to front-end without any framework, what would be the minimal boilerplate to deal with views and trees of components.<p>Webcomponents are OK for components but they don't really solve all problems React solves, like component aggregation, updating a component tree easily, and of course, testing without having to fire a browser instance (testing is the biggest reason as to why React is useful in my opinion).<p>We kind of have events covered with event delegation and custom events.<p>In my opinion, a native DOM diff algorithm as part of the DOM spec would already goes a long way for the teams who want to get rid of third party frameworks. It is very easy to build a view functionally (then use the visitor pattern to serialize functions into a DOM tree, which is basically, let's admit it, a poorman's XSL). Updating the DOM attached to a webpage is the hardest part in terms of performance and third party libraries aren't often as fast as they should be.<p>I'd be interested in hearing about alternative "frameworkless" approach regarding building interactive HTML pages without too much initial boilerplate (which can quickly turn into one owns framework anyway).