Startup development teams need to optimize for speed. Code needs to ship quickly to validate ideas, and it needs to turn on a dime as feedback comes in. Perfect code that solves the wrong problem or ships too late is of no use to the company.
But speed needs to be balanced with quality, and one of the most effective tools for ensuring quality (as well as sharing knowledge and coordinating) is code review.
Web frameworks are sneaky. They lure you in with their promises of just overriding one method, and (voila!) you have a web or API server.
But then time passes.
Suddenly you want to change something that the framework doesn’t make extensible. Or you spend hours debugging something deep in the bowels of the framework you’re using. Suddenly your framework is your enemy.
In fact, I’d argue the eventual frustrations from using a given web framework are directly proportional to the amount of magic it wows you with up front.
Reusing code of any kind involves a tradeoff between having control and moving faster. This is almost always worthwhile with libraries, which are easy to swap out over time. But web frameworks, even when pluggable, usually involve a magic abstraction over routing HTTP requests and finite points of extensibility. The tradeoff isn’t worth it in the long run. Sometimes it feels like the goal is “write as little code as possible,” when it should be “make this code as easy to write and maintain as possible” — declarative abstractions are not inherently better just because they’re aren’t code. It only takes a small amount of boilerplate application code and some libraries to make something just as functional as and much more versatile than a pre-built framework. …
Everybody is trying to get you to download their app.
It’s clear why they want to.
The story is more complicated if you’re a user. Sure, the app itself is a better experience, but