It's unfortunate, but many developers have the mindset of "The bigger the Application, the bigger framework I'll need!" When in reality you're better off with the opposite.

This is compounded by the fact that there's a much greater amount of service-style applications (Single-page web or mobile app backend) where a significant portion of Django's niceties (and there are many) are irrelevant to what you're trying to accomplish.

I think that he meant that Django has a bigger ecosystem with a lot of different apps, so you don't write everything from scratch. There are apps for migrations, building a REST api, having a tagging system, integration with search engines and many others. I won't comment on the state of the Flask ecosystem, because I don't know it, but I imagine it's smaller.

Here's the reality though: so many of those apps in the ecosystem are half-baked, unsupported, and don't actually work. It's a mess trying to match existing code to a set of customer requirements, all the time with the customer saying "Can't you just use django-foo?" ignoring the fact that django-foo was last upgraded 5 years ago and won't work with anything newer than django 1.4, and doesn't do half the things in their requirements anyway. It's pretty rare that any of those applications in the ecosystem actually save me any time.

There are plenty which are production ready and good quality. Some examples that I use are haystack, compressor and rest-framework. If the customer tells you to use a shitty app, explain to them why you can't. They don't know better. You're the expert.

I would kinda disagree here. Django's killer app starts (and almost ends) at the admin functionality. It's inferior to most other mainstream frameworks in other respects...but the admin is absolutely world class, which can be a huge time saver. I'm working on a commercial app now that has zero customer UI aside from the admin - which is used to configure a REST api.

Except the "killer app" Admin is derived from the coherence and functionality of the parts of Django. Without the ORM, or the templating structure, or middleware, or templatetags, or how apps are structured, etc. the admin would be little more than Bootstrap.

As such, the killer app of Django is Django.

Disagree. They're nothing about that combination that is special. It should just as easily have been built using, say, Jinja templates and SQL Alchemy ORM.

Not even a little bit.

Saying, "Oh, I could do that with X" is a bullshit statement. You could build an Django-like admin in Fortran.

Yes, you can hack together an admin tool in any templating system, using any ORM, or even raw SQL if you like. It's all just CRUD operations, and provided sufficient/consistent abstraction you can make it work, for your own project, without any troubles. You could, with sufficient work, even create an admin as simple as the register command.

This is the power the ecosystem at play though. When I snag a Django app to add to me project, it comes with an admin. I don't have to cobble one together.

I can replace the Django admin with an api-compatible alternative like Grappelli or Suit, and 98% of all the applications out there for Django will go right on working.

So the admin is not a killer app (per se) but is an example of how Django itself IS a killer app, because the admin is powered by it, and the community enabled by it.

I'm very confused by your argument. What is _special_ about the Django templating and ORM that enables the admin, besides "invented here"?

The special thing is the conventions.

The admin depends on uniform URL conventions driven by the framework and the URL reversion mechanism to get object URLs.

The CRUD DB functionality depends on the models being compatiable with the Django ORM interface, as well as the forms and the interations between the ORM and forms which allows for things like ModelForms.

The admin has its own set of important template tags to render information depending on the context, and that allows for consisten overriding and enhancing of functionality.

The imporant thing is that, even though all those components are decoupled, they were made in mind to interact flawlessly, and share idioms and interfaces that allow them to work together in ways that that more decoupled frameworks do not.

Finally, while there is nothing special about each component per se, most people seriously exaggerate the shortcomings of each, and there is no component in Django that is plainly bad, something that I have personally seen in pretty much every other framework I have worked with. Consistency is important.

It turns out that you have a Flask-admin plugin:

http://flask-admin.readthedocs.org/en/latest/index.html

I haven't used it, but looking at the quickstart, you gain a lot of flexibility in exchange for a bit of boilerplate. As I haven't done any Django in a long time, I cannot comment on how complete it is, but it shows that you can absolutely achieve this kind of functionality in a framework with a tiny core.

That's a huge huge statement saying its inferior to most other mainstream frameworks. I would love to know what you are basing this on as I would find it hard to make that statement.

Templates inferior to Jinga/Haml/pretty much anything that isn't ERB or XML based, DB ORM inferior to SQLAlchemy, etc. I'm not saying they're terrible, but they're certainly dated and don't reflect current state-of-the-art.

But that's not the point of Django; even the disadvantages (which admittedly exist) are pretty minor for even the worst cases.

The best thing about Django is that all apps respect the app structure, middlewares, URL dispatch mechanism, and template tags, so it is trivial to create detachable, modular applications and use them for your own project.

I can download one of dozens of applications that improve upon the provided functionality and the chances of there being an incompatibility are minor. Installing apps is trivial, migrating all your new applications' schema is consistent.

People truly underestimate just how imporant it is to have a framework with no surprises and consistency. This is something that Flask does not provide and weighs heavily when you need external functionality.

I wouldn't say they're always that minor. Comparing Django static assets with e.g. the Rails asset pipeline is like stepping into ancient history. Rails has a lot of developer quality of life stuff that is just snowballing.

I would say that Rail's asset pipeline is a contentious issue at best; not everyone needs, wants, or considered compressed assets to be a best practice, although I agree that some framework for support asset pipelines would be fine.

In any case, there are several extremely good 3rd-party asset pipelines

the admin stuff is really killer, but I think the ORM deserves mention as well (see my rant).

That seems more like a rant against Play (which I would mostly agree with). But e.g. SQLAlchemy ORM makes Django's look like almost a toy.

SQLAlchemy makes most queries significantly longer to write while not adding anything for 95% of the use cases. The fact that it's more powerful doesn't change the convenience of the Django ORM, and the fact that in practice it's not a problem.

The reason why I checked both out was because I wanted to try my hand at Python and see what all of the hoopla was about.

Unfortunately for me, the most memorable part of the experience was repeatedly calculating how many times I could have coded the exact same solution in PHP in the time it took me to finish a Flask project.

I actually have the same sensation, only for me it is about how much faster I could crank out a solution if I was using Flask or Tornado. Django is probably fine for proof-of-concept style applications within a certain set of requirements, but too often it gets used for applications beyond its scope.

I've had similar experiences with Ruby - I used Sinatra to write a really simple REST API, and while getting the core stuff working was relatively simple, there were many times towards the end when I wished I'd just written it in PHP.

Oh, and don't even get me started on deployment.

PHP deployment gets really painful at decent scales. The process model is very poor leading to both high memory usage and high server load.

How?

Because basically the interpreter starts from square one on each request. While some things can be held over (e.g. db pconnects) it's far from ideal.

I think we should get started on deployment considering how often it's swept under the rug as something that the "lowly sysadmins" have to deal with.

So you're saying that you would be more productive in a language that you've been using for longer.