5 ms·

I don't understand why people want to compare Django and Flask. Django is ideal for the freelancer or developer that needs great tools available at their dispo

I don't understand why people want to compare Django and Flask. Django is ideal for the freelancer or developer that needs great tools available at their disposal for quick and high-quality development. Flask is ideal for the large system and application where many components are expected to be built bottom-up and extra flexibility is needed. The intersection point for both use cases goes to the point where you're having several people working on a project full time, and at that point you'll likely have much more important things to be concerned about.

TylerE 13y ago
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.
- rtpg 13y ago
  the admin stuff is really killer, but I think the ORM deserves mention as well (see my rant).
  - TylerE 13y ago
    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.
    - Daishiman 13y ago
      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.
- avenger123 13y ago
  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.
  - TylerE 13y ago
    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.
    - Daishiman 13y ago
      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.
      - TylerE 13y ago
        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.
        Daishiman 13y ago
        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
- etchalon 13y ago
  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.
  - TylerE 13y ago
    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.
    - etchalon 13y ago
      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.
      - TylerE 13y ago
        I'm very confused by your argument. What is _special_ about the Django templating and ORM that enables the admin, besides "invented here"?
        Daishiman 13y ago
        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.
rmrfrmrf 13y ago
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.
- wldlyinaccurate 13y ago
  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.
  - rmrfrmrf 13y ago
    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.
  - TylerE 13y ago
    PHP deployment gets really painful at decent scales. The process model is very poor leading to both high memory usage and high server load.
    - jbeja 13y ago
      How?
      - TylerE 13y ago
        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.
- elbear 13y ago
  So you're saying that you would be more productive in a language that you've been using for longer.
spamizbad 13y ago
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.
- elbear 13y ago
  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.
  - poulsbohemian 13y ago
    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.
    - elbear 13y ago
      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.

TylerE 13y ago

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.

rtpg 13y ago
the admin stuff is really killer, but I think the ORM deserves mention as well (see my rant).
- TylerE 13y ago
  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.
  - Daishiman 13y ago
    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.
avenger123 13y ago
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.
- TylerE 13y ago
  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.
  - Daishiman 13y ago
    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.
    - TylerE 13y ago
      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.
      - Daishiman 13y ago
        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
etchalon 13y ago
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.
- TylerE 13y ago
  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.
  - etchalon 13y ago
    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.
    - TylerE 13y ago
      I'm very confused by your argument. What is _special_ about the Django templating and ORM that enables the admin, besides "invented here"?
      - Daishiman 13y ago
        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.

rmrfrmrf 13y ago

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.

wldlyinaccurate 13y ago
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.
- rmrfrmrf 13y ago
  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.
- TylerE 13y ago
  PHP deployment gets really painful at decent scales. The process model is very poor leading to both high memory usage and high server load.
  - jbeja 13y ago
    How?
    - TylerE 13y ago
      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.
elbear 13y ago
So you're saying that you would be more productive in a language that you've been using for longer.

spamizbad 13y ago

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.

elbear 13y ago
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.
- poulsbohemian 13y ago
  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.
  - elbear 13y ago
    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.