Really not a fan of this terminology, popularized by DHH/37S. The term "opinionated design" is basically an excuse to make a rigid, unadaptable behemoth, because it's easier to just say "if you don't like it, you don't have to use it" than to address some of the problems. There is a balance, of course, and you can't spend all your time abstracting out to support the most transformative, irregular use case, but something like mixing ORMs or templating languages is actually a great example. Look at Pyramid v. Django/the others. A web framework should simply be about piping your program's I/O to the web. Templating and ORM shouldn't even be in scope. Having reasonable defaults is fine, but claiming it's OK to tightly couple your general-use web framework with user-facing unrelated libraries as hard dependencies (i.e., forcing users to use a certain ORM/templater) because it's "opinionated design" is silly. It's simply bad design.
> A web framework should simply be about piping your program's I/O to the web [...] Templating and ORM shouldn't even be in scope.
nope. that's what a server gateway interface is for. giving you a set of reusable tools and conventions to help you work - that's what a framework is for. the scope of the framework can be wider or narrower and it depends what you like - it's just, like, your opinion, man. the so called microframeworks are cool, but they are not a remedy to every problem out there.
> forcing users to use a certain ORM/templater
forcing? not sticking with the defaults and building an exotic combo leaves you out of re-using a lot of the ecosystem apps, but certainly you are not "forced" to do anything.
I think it's important to note that not everyone wants or needs to choose every single component in a project. In fact, this can be a big waste of time and added complexity for some projects, particularly the more simple ones. Even for a larger project, your choice of template language is nowhere near as important as the quality and cohesiveness of your overall design (you know, the actual important stuff). With the move towards heavier API-driven client-side stuff, the choice of frameworks gets to be even more boring.
Django is easy to hire for, it's easy to get help for, it's easy to Google around for. I can plug in an intern and have him productive very quickly due to the great documentation, and the "opinionated" nature of Django (there are widely known best practices for lots of things) is great in this case. He doesn't have to wade through all of my glueing of pieces together, figure out this lesser known, lesser documented, lesser supported framework (Pyramid). He just says "Oh, this is Django, I get it."
I don't make the claim that Django is better than Pyramid, but I think it's probably foolish to do the reverse as well. They are just two different ways of doing things: minimalistic/bring your own lunch versus batteries included.
