This makes three shaky if not outright wrong presumptions: 1. The only reason to cutting out the framework is speed. There are many reasons to forego a framew

This makes three shaky if not outright wrong presumptions: 1. The only reason to cutting out the framework is speed. There are many reasons to forego a framework. Coupling, maintenance[1], dependencies or simply "keeping it simple" are some of the parameters to take into consideration when choosing for or against a (certain) framework. More practically: I'm writing a simple job search engine[2]. Plain, vanilla JS, some \<template\> tags, and a library to communicate with the search backend. I dont' yet need anything react-redux-saga-event-based yet. This approach is reaching its limit, but I now have the proper information to make a better choice. I did not have that when I started, so I would've certainly picked the wrong framework and painted myself in a corner there. 2. Without a framework we cannot iterate quickly As I point out in my blog[1] article, this is has often (but not always) be proven to be exactly opposite. Obviously depending on context and use-case. But there are many situations in which a framework is holding you back. In which it is actually slowing the project down, rather than speeding it up. Frameworks, famously, allow a rapid start, and therefore are great for PoCs, Demos, prototypes, MVPs or even "run-off-the-mill-agency-produce". But over time (think years, decades) often get in the way, hold the project back. Just think of the wasted eons of all engineers "rewriting project P from scratch"; often because it turns out that the current version/market/tech/use requires things that no longer fit the boundaries the framework imposed. Bouddaries welcomed or disregarded when the framework was chosen a decade (or just years) ago. 3. Smaller teams need a framework See above. But also: what a small team needs is reusable code. Libraries. Not Frameworks per-sé, but libraries. Preferably implemented behind decoupled, isolated layers; away from business-logic. Or, more modern, SAAS, PAAS, IAAS. reusable stuff, preferably implemented behind isolated layers. [1] https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010 [2] https://search.flockingbird.social/ https://search.flockingbird.social/