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

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. The "legacy/debt" issue is more interesting matter. React and Angular are obviously big right now so most shops go with these. 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. 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). We kind of have events covered with event delegation and custom events. 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. 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).