I think this is a pretty succinct counterpoint. I especially agree the sunk-cost of investing time learning a framework isn't something to take lightly. The on

I think this is a pretty succinct counterpoint. I especially agree the sunk-cost of investing time learning a framework isn't something to take lightly. The only thing I'd counter to this with is when I see this approach taken, an informal "framework" of sorts tends to evolve naturally. First you write something that handles the routing, then soon you want to organize the code the route endpoints call, then you layer on the authentication at the top level request handling area, so on and so forth. Over time, as new requirements come in and new people work on the project, more and more patterns, conventions, and library are added to the codebase - pretty soon all that "glue" code meant for interfacing with libraries is reaching or exceeding the complexity of a framework based codebase (except your codebase probably has less documentation for things like conventions and patterns than a framework would). That said, I don't think it's the wrong approach especially when the scope of the project is limited and/or there are ways to manage feature creep (e.g., frontend only, limited lifespan, internal facing apps, etc)