For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks.
A few specific things I like about Django:
1. A decent app ecosystem
2. Lots of documentation and a fairly mature codebase.
I never really loved them until I started working on a massive Django project with Oracle. South doesn't support Oracle, and now I have to manually tweak tables every time I update a schema.
The company I work for just switched _to_ south from a custom migration system and it has been really awesome. It streamlined out development process a bit as well.
He never said they were specific to Django, he was mentioning a few specific things he liked about Django.
It's great you like Pyramid, but honestly, a lot of this is just a matter of taste. I personally find the way Pyramid fits together and its documentation less appealing than Django. In my dabblings with Pyramid, I found the community less responsive and helpful. But that's all subjective and anecdotal, just like your take on Django (which is why this is a boring discussion).
The truth is, good engineers can do great things with far less than Django or Pyramid. The choice of framework is a very boring discussion, since most modern, widely used options are going to be "good enough" in the right hands. Your idea and its execution are front and center. If you're sufficiently skilled, your framework shouldn't be a huge factor in your execution.
Pick something that you like, and just get to work.
Right, I never said it was impossible to build something useful in Django. I just believe it's a non-optimal choice, in almost any situation. I don't believe "it's just a matter of taste" to have a web framework that knows its place and makes it simple to adapt, or unpretentiously allows you to code with minimal rigidity. I don't find any contrary arguments presented thus far convincing.
Saying that Pyramid's documentation and overall "fit" is "less appealing" is a matter of taste. Indicating that Django is much bigger is a matter of fact, and that it provides little if any additional benefit and increases rigidity and practical obligation to conventions is a matter of informed analysis. The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived. it's nothing personal to Django or the people involved in it (I've even submitted patches, but to my knowledge, they were not merged). It's just a thing that has been superseded, and that happens in tech. Now it's just a matter of how long until everyone else can drop the religion and admit they're wasting time on compliance and rigidity that shouldn't be there.
I'm not saying Django is the least productive framework in existence. I'm not saying it'll ruin your company or life if you use it. I know people who use it and we are able to get along. I work with it occasionally. I'm just saying, "it's unwise", for almost any large-scale new project.
> I just believe it's a non-optimal choice, in almost any situation.
And this is where your argument loses every bit of credibility, this is an awful, unsubstantiated blanket statement. I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
> The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
I think you're missing the point entirely. Your claims of rigidity aren't applicable for everyone. For a very large number of users, Django doesn't need to be super de-duper modular/interchangeable (it's good enough for many/most). In fact, some people don't want the complexity of SQLAlchemy. Some don't even know/care what jinja is (I personally haven't felt the desire to switch to it, as I feel it has problems of its own).
Django is batteries included. Pyramid is not. These are two different approaches that each have tradeoffs.
> It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived.
Again, not everyone wants these pieces you are talking about. While SQLAlchemy is a great piece of a software, it is a complex piece of software with a steeper learning curve than the simple Django ORM. There are plenty that don't need/want something as heavy duty as SQLAlchemy. In my case, if I need the absolute best performance or advanced features, I am writing SQL instead of dealing with any ORM that makes bad choices for me. More ORM is not attractive to me, I tend to dislike them for anything but the most simple cases (ie: the basic Django ORM operations).
That is where your blanket statement falls to tatters. Differing requirements, different priorities.
> I'm just saying, "it's unwise", for almost any large-scale new project.
And not all advice is created equally :) I'd say that it is appropriate for some large-scale projects and teams, and inappropriate for others. It's flat out wrong to make a blanket statement like yours.
No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
If you want simple, you can use adaptive frameworks simply. They come with defaults just like Django does. The difference is that it's easy to swap or mix-and-match components, and it's an intended use case. On Django, if you don't go with vanilla, it's a hack.
As I wrote elsewhere, "batteries included" doesn't (or shouldn't) mean "batteries hard-welded". It's fine to include stuff and have defaults; adaptive frameworks have these too, but they considered the fact that someone may want to do something irregular at some point and that it shouldn't be a world-breaking experience for that to happen. A framework that understands its place is all gain, in that it doesn't intrude and try to force something, and no loss, in that it also comes with defaults that you can just use if you aren't yet at a stage where you'd have a reason to replace them, and therefore, from an objective technical standpoint, it is a better choice. Perhaps social issues override this in some situations, but those can't be considered in our removed, objective, technical context.
>I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
It doesn't matter if there are success stories. I'll repeat myself, I guess, and say that I don't intend to say that Django is useless or terrible or that it does nothing and will ruin your life. The point is that most people who choose Django for technical (not social like "we all already know django") reasons are making an incorrect choice. For now "we all already know django" is acceptable, just like "well we all already know SVN" was, but at some point it won't cut it anymore, and you'll be expected to adapt.
>Django is batteries included. Pyramid is not.
I disagree. Pyramid comes with batteries. It has a full stack ready to go for you if you just want to open it up and code, just like Django does. The difference is that Pyramid allows you to tweak or swap freely as necessary, and Django makes it difficult.
>It's flat out wrong to make a blanket statement like yours.
No, it isn't. My blanket statement is generally but not all inclusive. Is it wrong to say "Using Windows 2000 as the primary hosting platform for new projects is almost always wrong"? Things change in tech. Rigid generic frameworks that try to dictate templaters and ORMs are old hat, they are plainly incorrect for all but the most esoteric use cases. There is no good reason to do this.
Is Django going to disappear overnight? No, but I hope that people can get past their holy wars and take a serious objective analysis. Consider that you're actually against a useful feature set just because the less-powerful solution is often "good enough". That's not a reason to choose a thing, it's just a reason not to flee from a thing. I'm not saying every Django app needs to be rewritten, but I do think it's silly to settle on "good enough" for new stuff when "much better" is available at little or no downside.
> No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
This reminds me of when ROR came out and "opinionated frameworks" were the new black. I can kind of see where parent is coming from - lightweight frameworks are lightweight because they rely on external components (eg, ORM, form-handling libraries...) which are so many moving parts, and not always well integrated with the framework. On the other hand, I've found that the Flask plugin ecosystem works pretty well as very lightweight glue with other components.
And let's face it: even with a "batteries included" framework, you'll eventually have to go out and get a third-party battery which was not included.
Django rigidity with the ORM and template language brings one major advantage: Reusable applications developed for Django are pretty much guaranted to use them. So you can aggregate them without having to deal with 3 different ORM or template languages.
Yes, django reusable apps are not always top notch quality and always maintained properly. And sometimes you will need to dicth all the templates and create your own. But you sometimes get an important piece of software for free or at least a good base to start your work.
I feel that with a more "flexible" framework the integration of apps coded by different teams will be more problematic.
I'm sorry, there are just too many absolutes and far too much hyperbole in your response for it to even be taken seriously.
This "Rigid" term you keep throwing around is absolutely ridiculous. It seems to be the entire basis of your argument, but you fail to back it up at all. Django makes some decisions for you, but you can almost always go another route. It's all just Python.
"<Vague blabbering about 'rigidity'>. Boo Django, yay Pyramid!" - cookiecaper
A few specific things I like about Django:
1. A decent app ecosystem
2. Lots of documentation and a fairly mature codebase.
3. Django south for migrations.