It is very easy to say "Django has large design problems" and go on about how it "imposes ilegitimate requirements". Truth is that Django is a framework and by definition, frameworks give you a way/structure to do things. If you don't want a framework, then there are several other options. The strength of Django comes from the huge quantity of packages you can swap in/out. You mentioned you don't like the Django Template engine and that Jinja s better. Easy to swap. Don't like the authentication? Swap it out for something else or use a custom one. Don't like the ORM? Dont't use it... sadly you'll be missing out on south which has saved me from sql schema and data migration headaches. Caching? Redis, Memcache, or write your own. It plugs easily. Async processing? Celery is only a few lines of code away. Indexing with Sphinx search or Lucene is trivial. Want to add automatic CSS/JS minification + bundling + sprite generation + cache busting? There are django apps for that. Need analytics? You only need two methods for middleware. I could go on forever... The point is that this is exactly what I expect from a framework. If the framework doesn't do it, the somebody has to - and that means it is me.

It's about the rigidity of the structure given. A framework is supposed to give me the tools and structure I need to do what I brought the framework in to do. On a web framework, that is to pipe I/O over the web, give me access to web-layer stuff like the request object, and provide a few other simple structural niceties like MVC (which itself is quite flexible in Pyramid (optionally, of course)). I don't want it constraining me to the point where the world breaks if I decide the default ORM or template is not making the cut.

As for all the things you've mentioned, it's perfectly plausible to have those things occur in Sinatra/Flask/Pyramid/whatever. The structures they provide are sufficient to hook up the kind of things you've mentioned. It's only that smaller communities have fewer pre-packaged solutions. In most cases, if you're building a new, serious platform, you'll want to use something that you can believe in technically, even if initially you'll have to contribute some of those modules yourself. You must be willing to invest in things you believe in, or they will die.

I am sorry, but I am still failing to see your point. Let me address the specifics issues you brought up:

Accessing the request object? In Django, there is a RequestContext that can be accessed all over the place (e.g. middleware, views, templates or wherever else you wish to pass it through). It has many helper methods that parse several thing only one method call away.

The template engine? I have used Jinja in some projects with Django. It literally takes less than five lines of code to swap out. Look it up.

The Django ORM? Don't make the calls. I have done a handful of projects where doing everything through the ORM would have been a really bad decision since the web app was mostly about being a front end for an analytics system with processing that took from hours to days to complete. Instead, I wrote raw PostgreSQL/PostGIS SQL queries all over the place that ran asynchronous and hooked up Hadoop Clusters for other items... everything being controlled through django-celery. It was really easy to do. The state currently uses it to do "serious" pollution, health and city growth analysis, hence why I fail to see your point.

You mentioned Sinatra/Flask/Pyramid and such. Thore are good frameworks, but you also acknowledge that there are "smaller communities in few cases" and my point is that is exactly where django shines: the ecosystem.

I like to build "new serious platforms", too. To do that, I use whatever is appropriate from Django and the community and I have yet to stumble upon something that keeps me stuck because of the decision I made.

Granted, it is a hammer and sometimes you need a drill. Let me give you an example: One of the apps I needed to write is a realtime geolocation service. For that, I use websockets and node.js because of its non-blocking and persisted connection nature. Does that mean that I need to ditch Django altogether? Hell no, I let the front reverse proxy direct the websocket traffic to node.js and the rest to django. My node.js code is so tiny because it is just a Pub/Sub client proxy. Most of the work is done in async Celery/RabbitMQ workers (that use the Django ORM by the way). Doing this with Django is easy (well, to be fair, the credit should go to the vast amount of python libraries).

I "believe [in Django] technically"... why? Because in the four years I have been using it I have yet to get stuck because of my decision to pick it. I don't use it for everything, but I do for 99% of web related work. Once again to the risk of repeating myself, I pick and choose the Django parts I need in a per-project basis. Funny enough, I still laugh everytime somebody complains about some performance thing and I pretty much see their face jaw drop to the ground when I install varnish in front, change two lines of code to tweak the expiration headers, and deploy the static content with a good CDN. 5x performance is not surprising. Yes, there are several Django apps that make this trivial to do.

Sorry I still don't see the specifics of the points you are trying to make.

Opinionated design is not "bad design with attitude". You may disagree with the opinons, but those opinions are thought through and made for the best interests of all the users. It is not uncommon for you to sit in the outside the "norms" the framework is shooting for, but that is not a problem for either you or the framework. A framework that tries to be all things to all people generally sucks for everybody.

>A framework that tries to be all things to all people generally sucks for everybody.

Right, I agree. I like a framework that tries to be a generic web framework for most people who want to write a typical web application in Python. That seems adequately specific to me. I don't consider that "opinionated design", it's simply identifying a market.

"Opinionated design" is an excuse to make interopability and cross-compatibility difficult. There are, generally speaking, few good reasons to do this. Things that are totally out of scope obviously shouldn't be integrated, but if you feel the need to bundle a certain type of library with your framework, shouldn't it be sensible that someone might want to tweak that someday, or replace it with another library that does the same thing in a different way? Opinionated design is about copping out of that logic and putting a smooth sheen on it, it's saying "OK, we understand this is a reasonable, in-scope requirement, but we're opinionated and cool, like Steve Jobs, so we're just going to say you have to use this library or you're SOL. Remember, we are cool like Apple, and that's why we can tell you off in this fashion". Not "only projects that implement this prudent, adaptive, and objectively important-for-our-use-case protocol will work", but "only this library" or "only this way".

Projects that don't suffer from scope creep or far-fetched, irrelevant integration aren't called "opinionated design", they're simply called "well-managed". It doesn't come from having an opinion and telling everyone else to shove it. It comes from having goals and the discipline, reason, and structure in place to stick to them.