[Glyptodon]

The only thing I'd really take much issue with is the "provides great defaults" statement made in passing. There are several things that are defaulted more to what I'd call "lowest common denominator" than "great." For example, sessions.

[patsplat]

This a great point that gets to the heart of the problem with the premise of a full-stack framework. Defaults end up more "good enough" rather than "great"

[Daishiman]

But a collection of consistently good enough components is better than tying together two dozen different things of wildly different quality and conventions.

I hear this a lot about Django. The ORM is really good but "not as good as SQLAlchemy". The templates are great but "Jinja is better".

The thing is that as an engineer I value that the components are incremental improvements with sane defaults where change is deliberate and the benefits of what I'm missing out on are truly, honestly irrelevant. There's really very few times where I said to myself, "Oh of only my templating language had better support for these idioms". I just write a decent workaround because I've been using the same tool for years and it's maintainable and the total number of workarounds is so small that there are no good reasons to switch to an alternative even in the long term.

This is much better than the alternative of looking for 5 alternatives for the same component, discarding the first 3, using one for a month until I find it has fatal flaws, and finally settling for the last one.

[patsplat]

Once one critical component in the framework is no longer good enough it can be very difficult to upgrade.

Frameworks aggregate many dependencies. Managing the dependencies that deliver value while ignoring those that are irrelevant can net out as more productive.