I disagree. Had you added "in some situations" I wouldn't.

The point of the frameworks, which are heavily coupled components with many constraints, conventions and hidden parts of functionality is rapid prototyping. That means that you can go from 0 to something quickly without knowing all the details. For a large class of use-cases the ability to get something out there fast is more important than the technical debt you may incur by not knowing how everything is loaded. This is the case for a lot of new products, startups and such.

On the flipside, if you have a very solid spec of what you're building (for example, if you are re-writing an already-existing piece of software with a browser-level test suite as spec so that it is easier to scale) then loosely coupled components are likely the way to go. And yes, as soon as scale comes into question loosely coupled components that you understand well are the way to do it. This just isn't always the case.

Secondly, it is not clear whether the frameworks get in your way that much. I remember reading a blogpost about a shop replacing django bit by bit until there was no django. That seems pretty cool. On the other hand, there is disqus, which used django from the get-go, I think, and haven't swapped it out, but just built a lot of tools around it. On the third hand, there is probably a lot of sites that start with loosely coupled components and keep refining. They are all valid approaches. At the time you are starting it is usually unclear how to go about it.

In general I agree that people should try to understand how their tools work, but there are only so many hours in a day, y'know?

Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much.

I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention.

I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is no surprise, of course, since it comes from the same guys who made the Sphinx documentation builder.

I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.

- Use a framework that has adequate components that are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework.

- Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code.

I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well.

That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc.

Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django.

[1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month.

Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.

On the other hand, for this specific app -- bottle, itty and juno all look very similar to the app made with flask. For whatever reason I find this very Pythonic.

This is the _main_ reason I chose Flask to work on a new project. After using our in-house proprietary framework for a year and a half, I wanted to see if I could do any better. But the HTTP request part sounded boring. Enter Flask: it let's me grow the framework into exactly what I want it to be.