[onion2k]

But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.

It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better.

All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.

[tekknik]

There are a couple of reasons you want a “quickly spun up” framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you’ll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down.

So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.

[KurtMueller]

Or you don't really know the problem space quit yet and an application that helps you get up and running quickly allows you to figure it out in a short amount of time. Maybe you find out that your preferred tech stack is not adequate, at which time you can change it.