Using a large framework like Django should allow you to use "as much reusable components" at any time, plus you have the advantage of knowing that they will play nicely together, and should have some sort of consistency between them. Yes you get a bigger download, but it will be stored on the server, not downloaded each time a user clicks a link. Less dependencies, as more is included out of the box.
try doing something workflow heavy on appengine with datastore. The django orm wont work for datastore, so what you are left with out of the framework is regex based routing(ewww) and a bunch of crippled components(meaning depending on an orm you can't use).
django has it's place dont get me wrong, i would use it to quickly squeeze out internal db backed apps all day. maybe even use it as a cms. But i'd rather not do those kinds of projects at all.
You believe it, I tried it, and it failed, the non-rel project isn't even under active development anymore. And if appengine had not introduced cloudsql as an option, django would be useless on that platform.(IMO)
> And also Django is modular enough that you only need to use the parts you require.
As I said before, without the django orm, there's not much useful stuff left in django that will work without it. There's better request routing options than regex based IMO. There's better form libs and validation libs. There are certainly better performing template engines, what is left of django that's a better choice over something else?
Or... more unnecessary dependencies you're forced to code around if you happen not to want or need them.
Sure things are included and make Django a bigger download than microframeworks, but other than a bit of disk space on the server, I have never had a problem with parts of the framework I don't need.