15 ms·

Django vs. Flask for a long-term project

39 points by notastartup 13y ago

nkuttler 13y ago
No. Django is "The Web framework for perfectionists with deadlines". Sometimes you just need to get things done, and not to optimize prematurely. And seriously, if you replace every Django component with something else you probably picked the wrong tool for the job.
- poulsbohemian 13y ago
  That's actually the root of my issue with django. It's a vanilla MVC framework with a scaffolding admin interface and an ORM layer. It's popular because it's relatively easy to get started ("the Rails of python"), and thus too often it gets picked by default. The problem is that too often my customers have already picked it, have run headlong into development, then I walk in and have to ask why they picked django when their requirements don't match any of its architecture assumptions.
metaphorm 13y ago
no. what's there to discuss? the only part of Django that is reasonable to replace is the template system, which can be replaced without difficulty or loss of functionality. Its fine if you decide that you don't want to use Django and build a more modular stack with components of your choice. If you decide to use Django you're deciding that you want to use Django's ORM, URL routing, util libraries, etc. These are all really high quality components that do their job well. There's no good reason to replace them once you've started using them.
eitland 13y ago
It is correct according to the rules of stackoverflow but the wording "closed as not constructive" is still w r o n g. "Closed because there is a fair chance it will not be constructive" maybe? "Closed because this and this and that person felt there where a fair chance it would not be constructive?" Oh, by the way: discourse is still a sandbox it seems: from http://try.discourse.org/ http://try.discourse.org/ - "THIS SITE IS A SANDBOX – it is reset every day"
- rmrfrmrf 13y ago
  I see crying like this all the time from people that hate StackOverflow, but (surprise!) there is not a single constructive answer on that page. The top voted answer starts with "Personally"! It has been said time and time again that StackOverflow is not meant to be a masturbratory playground for theoretical development; it's meant for discrete problems with discrete solutions. That's not to say that there isn't a need for a site that discusses the pros and cons of different development tools ad nauseum, but that use case is explicitly outside of the scope of StackOverflow.
- astrodust 13y ago
  That's the Discourse demo site. What's wrong with resetting it every day?
Daishiman 13y ago
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
collyw 13y ago
I don't really get the whole push to minimalist frameworks, from people that say Django is too bloated. It takes up 46 Mb of disk space on my machine. That is nothing these days. If you don't need a component, don't use it.
- rtpg 13y ago
  I think it's more in terms of code space. With flask you can arguably write the one-file webapp
- erichurkman 13y ago
  And even then, a lot of that code size is not code, but localization files, which are not exactly small.
- sophacles 13y ago
  I think it's a misunderstanding stemming from loose terminology... and the code size thing is resultingly a strawman. Bloated also tends to mean things like "takes up way too much conceptual space". Which is a valid argument against a lot of frameworks. The idea being: i have to learn to think about the problem in the framework's way, and restructure my solution around it. The opposite being: with micro-frameworks I can just wrap my app with the framework and get some functionality out of it that would otherwise be difficult or boiler-plate. (The counter-counter being: then you end up having to reimplement a buggy version of a full framework anyway as requirements grow and change...) The real solution is to not think of it as either/or , but as "both, sometimes".
  - TylerE 13y ago
    The other counter argument: You have features, A, B, and C. FullStack Framework 1 provides A+B+C, Lightweight Framework 2 Provides A+C, Lightweight Framework 2 provides A+B, minimalist Framework 4 provides B only. Are you better off learning (and keeping in your head) framework 1 only, or 3 smaller frameworks, which still doesn't cover the C+B case.
    - collyw 13y ago
rtpg 13y ago
Django has loads of goodies, but for me, by far, the ORM is my favorite part. RDB managment is the biggest snorefest in all of software development. There are some times where you have to figure out some crazy select or whatever, but for the most part it's annoying, easy to break, and it takes forever. Django lets me not think about it at all (granted, I'm not writing crazy search things either). When I started trying out Play Framework (for Scala, because I love type checking) I was absolutely shocked at the lack of an ORM. DB managment is the most boilerplate-y aspect of writing some CRUD, and Play decides not to help you with it. Their arguments are about "control" and how somehow "SQL is the best DSL" (http://www.playframework.com/documentation/2.0.1/ScalaAnorm http://www.playframework.com/documentation/2.0.1/ScalaAnorm). >val id: Int = SQL("insert into City(name, country) values ({name}, {country}") .on("Cambridge", "New Zealand").executeInsert() Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() /endrant I really like ORMs, and django has the distinction of having the best ORM in my book. I sincerely hope Django would never be reduced to Flask, because I care a lot more about having DB management work without me ripping my hair out than having routes or being able to put everything in one file. EDIT: for context, I don't ever have to do complicated things with databases, mainly tedious ones, which is probably why my vision of the world might be slightly different than yours.
- rmrfrmrf 13y ago
  Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() I had no idea that New Zealand was a city! Can I ask how the cities of Cambridge and New Zealand are related, though? Is one like the billing city and the other the shipping city?
  - eurleif 13y ago
    So use keyword arguments if you really find that so confusing: >City(name="Cambridge", country="New Zealand").save() Doesn't change the point about SQL.
    - rmrfrmrf 13y ago
raverbashing 13y ago
I can assure you that there are big sites out there using Django and "not replacing every part of it with something else" Yes, there is a need for manual SQL queries sometimes, and heavy caching, but for the most part it works ok. I'm not sure I can disclose the exact company, since I left them recently, so I won't, unfortunately.
thruflo 13y ago
> We don’t think it’s a universally reasonable suggestion to write “small apps” in a “small framework” and “big apps” in a “big framework”. You can’t really know to what size every application will eventually grow. We don’t really want to have to rewrite a previously small application in another framework when it gets “too big”. We believe the current binary distinction between frameworks for small and large applications is just false; a well-designed framework should be able to be good at both. Pyramid strives to be that kind of framework. http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introduction.html#what-makes-pyramid-unique http://docs.pylonsproject.org/projects/pyramid/en/latest/nar...
detroitcoder 13y ago
When I am teaching someone programming from scratch with Python, I usually get to Flask by day 3/4. Other than having to use decorators that look confusing at first, it is very intuitive and a quick win for newcomers looking for results.
27182818284 13y ago
if you go with django, then in the long term, you will have to replace almost every single component of django with something else, the only remaining part will be the url mapper. That has been exactly my experience with a project and it has eaten a lot of time It is the single reason why I'm abandoning Django. Batteries are included, but they are Double DD batteries when I need AA, AAA, etc, etc.
- debrice 13y ago
  Same here, the remaining is the URL mapper... which I really dislike BTW.
- Spiritus 13y ago
  I feel the other way around, granted I've played around with Django more than Flask. But the first thing I do when creating a Flask app is pretty much pip installing a bunch of packages to cover the basic functionality Django already provides like an ORM, forms, admin etc.
  - 27182818284 13y ago
    For what it is worth, I think Django just needs to be updated in a sense. For example, instead of just form.as_p and form.as_table, they should have form.as_bootstrap which you can do separately anyway, but of course that makes it a separate other thing that I need to reach for.
bkeating 13y ago
This last past year, at DjangoCon US • Chicago, I had the pleasure of sitting at the same table as Jacob Kaplan-Moss for the Speakers dinner prior to the conference. Very cool experience. My first. I brought up Flask and asked him what he thought of it. I had recently used it for a project for the first time and likely only did so because I was SUPPOSE TO BE FOCUSING on Django and preparing a talk about it. So naturally, I procrasinated and did everything but. It's been on my radar for awhile. I was attracted to it by it's documentation. Turns out, I really enjoyed it. It felt familiar because I've used Django for so long. I brought this up at the dinner table. Jacob said something that took me by surprise. I can't quote him exactly--the wine and drinks were too good that evening, but it was something to the effect of "Flask is what Django should have been". Another fellow from our table chimed in and added "If only Django had existed before we created Django!" What he ment was, without Django, Flask wouldn't of had such a clear and smooth start. Django taught us a lot. What I took from this was, both have their place and we have a lot to be thankful for, especially coming from the Django community. In regards to longevity, I think community is a major factor but these two technolgoies are both under Python, and I think the Python community at-large is what matters here. Hearing what Jacob had to say on Flask was sobering. There is no end-all-be-all, and both of these technolgoies have more in common than not.
timtadh 13y ago
I wish the pyramid project, http://docs.pylonsproject.org/projects/pyramid/en/latest/ http://docs.pylonsproject.org/projects/pyramid/en/latest/ , would get some more love in the larger community. It is a really great python web framework which gets a lot of things right and is easy to extend and customize. It doesn't enforce specific project layouts but is still easy setup and get going. I have used it now on 3 projects and they have all been very successful. edit: some background on pyramid's design: http://docs.pylonsproject.org/projects/pyramid/en/latest/designdefense.html http://docs.pylonsproject.org/projects/pyramid/en/latest/des...
Spiritus 13y ago
I've mostly been doing Django stuff. But I had a really hard time scaling my Flask app beyond a single file, I just didn't get how to structure my code.
- mercurial 13y ago
  When I first read about Django's documentation, I found its notion of "apps" brilliant. It turns out that Flask introduced blueprints a while ago: http://flask.pocoo.org/docs/blueprints/ http://flask.pocoo.org/docs/blueprints/ Like the rest of Flask, it's well thought-out and flexible.
TYPE_FASTER 13y ago
ORM - you'll write a little more code with Flask + SQLAlchemy to get the same result as using the Django ORM. With Flask, you'll have the flexibility of being able to, say, change a repository implementation to use NoSQL for some set of your models. Authentication - Django provides UIs that you can skin/replace, and there are Django applications to do OAuth for you. With Flask there are plugins, you have to provide a UI (and UI workflow). For almost everything Django can do, there is Flask plugin. You might be able to put together simple sites faster with Django, you will get more flexibility with Flask.
youngrok 13y ago
Well, I don't think the choice of framework matters for a large project. What matters is the language, and both use python. Frameworks are only starting point. When you build a large software, there would be many things that framework cannot cover up. No matter how frameworks organize parts of a large software, it's not enough. You should organize by python way, not by django way or flask way. Django app concept? It's good, but what if a single app grows too big? Split two apps? Then what if a project has hundreds apps? We should break down with python modules and packages for a large software. Flask is simple, and it's good for beginners. But is the simplicity helpful for a long-term project? It saves only learning curve of first week. Django supports many features and that's also good, but it only saves time to develop the features. Because flask already supports a lot, the saved time would not be much for a long-term project. Django or Flask matters only for small projects, such as one month long. The choice doesn't matter for a large project. Yes, django template sucks, but you can change to mako or jinja or something else. You like django ORM? That's a good news, but even if you don't like it, you can use SQLAlchemy in django. Such changes can be wastes of time for short-term project, but no problem for large projects. Code pythonic. That's the answer.

39 points by notastartup 13y ago

No. Django is "The Web framework for perfectionists with deadlines". Sometimes you just need to get things done, and not to optimize prematurely. And seriously, if you replace every Django component with something else you probably picked the wrong tool for the job.

poulsbohemian 13y ago
That's actually the root of my issue with django. It's a vanilla MVC framework with a scaffolding admin interface and an ORM layer. It's popular because it's relatively easy to get started ("the Rails of python"), and thus too often it gets picked by default. The problem is that too often my customers have already picked it, have run headlong into development, then I walk in and have to ask why they picked django when their requirements don't match any of its architecture assumptions.

metaphorm 13y ago

no. what's there to discuss? the only part of Django that is reasonable to replace is the template system, which can be replaced without difficulty or loss of functionality. Its fine if you decide that you don't want to use Django and build a more modular stack with components of your choice. If you decide to use Django you're deciding that you want to use Django's ORM, URL routing, util libraries, etc. These are all really high quality components that do their job well. There's no good reason to replace them once you've started using them.

eitland 13y ago

It is correct according to the rules of stackoverflow but the wording "closed as not constructive" is still w r o n g. "Closed because there is a fair chance it will not be constructive" maybe? "Closed because this and this and that person felt there where a fair chance it would not be constructive?" Oh, by the way: discourse is still a sandbox it seems: from http://try.discourse.org/ http://try.discourse.org/ - "THIS SITE IS A SANDBOX – it is reset every day"

rmrfrmrf 13y ago
I see crying like this all the time from people that hate StackOverflow, but (surprise!) there is not a single constructive answer on that page. The top voted answer starts with "Personally"! It has been said time and time again that StackOverflow is not meant to be a masturbratory playground for theoretical development; it's meant for discrete problems with discrete solutions. That's not to say that there isn't a need for a site that discusses the pros and cons of different development tools ad nauseum, but that use case is explicitly outside of the scope of StackOverflow.
astrodust 13y ago
That's the Discourse demo site. What's wrong with resetting it every day?

Daishiman 13y ago

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

collyw 13y ago

I don't really get the whole push to minimalist frameworks, from people that say Django is too bloated. It takes up 46 Mb of disk space on my machine. That is nothing these days. If you don't need a component, don't use it.

rtpg 13y ago
I think it's more in terms of code space. With flask you can arguably write the one-file webapp
erichurkman 13y ago
And even then, a lot of that code size is not code, but localization files, which are not exactly small.
sophacles 13y ago
I think it's a misunderstanding stemming from loose terminology... and the code size thing is resultingly a strawman. Bloated also tends to mean things like "takes up way too much conceptual space". Which is a valid argument against a lot of frameworks. The idea being: i have to learn to think about the problem in the framework's way, and restructure my solution around it. The opposite being: with micro-frameworks I can just wrap my app with the framework and get some functionality out of it that would otherwise be difficult or boiler-plate. (The counter-counter being: then you end up having to reimplement a buggy version of a full framework anyway as requirements grow and change...) The real solution is to not think of it as either/or , but as "both, sometimes".
- TylerE 13y ago
  The other counter argument: You have features, A, B, and C. FullStack Framework 1 provides A+B+C, Lightweight Framework 2 Provides A+C, Lightweight Framework 2 provides A+B, minimalist Framework 4 provides B only. Are you better off learning (and keeping in your head) framework 1 only, or 3 smaller frameworks, which still doesn't cover the C+B case.
  - collyw 13y ago

rtpg 13y ago

Django has loads of goodies, but for me, by far, the ORM is my favorite part. RDB managment is the biggest snorefest in all of software development. There are some times where you have to figure out some crazy select or whatever, but for the most part it's annoying, easy to break, and it takes forever. Django lets me not think about it at all (granted, I'm not writing crazy search things either). When I started trying out Play Framework (for Scala, because I love type checking) I was absolutely shocked at the lack of an ORM. DB managment is the most boilerplate-y aspect of writing some CRUD, and Play decides not to help you with it. Their arguments are about "control" and how somehow "SQL is the best DSL" (http://www.playframework.com/documentation/2.0.1/ScalaAnorm http://www.playframework.com/documentation/2.0.1/ScalaAnorm). >val id: Int = SQL("insert into City(name, country) values ({name}, {country}") .on("Cambridge", "New Zealand").executeInsert() Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() /endrant I really like ORMs, and django has the distinction of having the best ORM in my book. I sincerely hope Django would never be reduced to Flask, because I care a lot more about having DB management work without me ripping my hair out than having routes or being able to put everything in one file. EDIT: for context, I don't ever have to do complicated things with databases, mainly tedious ones, which is probably why my vision of the world might be slightly different than yours.

rmrfrmrf 13y ago
Who could possibly think this "DSL" is 'better' than something like >City("Cambridge","New Zealand").save() I had no idea that New Zealand was a city! Can I ask how the cities of Cambridge and New Zealand are related, though? Is one like the billing city and the other the shipping city?
- eurleif 13y ago
  So use keyword arguments if you really find that so confusing: >City(name="Cambridge", country="New Zealand").save() Doesn't change the point about SQL.
  - rmrfrmrf 13y ago

raverbashing 13y ago

I can assure you that there are big sites out there using Django and "not replacing every part of it with something else" Yes, there is a need for manual SQL queries sometimes, and heavy caching, but for the most part it works ok. I'm not sure I can disclose the exact company, since I left them recently, so I won't, unfortunately.

thruflo 13y ago

> We don’t think it’s a universally reasonable suggestion to write “small apps” in a “small framework” and “big apps” in a “big framework”. You can’t really know to what size every application will eventually grow. We don’t really want to have to rewrite a previously small application in another framework when it gets “too big”. We believe the current binary distinction between frameworks for small and large applications is just false; a well-designed framework should be able to be good at both. Pyramid strives to be that kind of framework. http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introduction.html#what-makes-pyramid-unique http://docs.pylonsproject.org/projects/pyramid/en/latest/nar...

detroitcoder 13y ago

When I am teaching someone programming from scratch with Python, I usually get to Flask by day 3/4. Other than having to use decorators that look confusing at first, it is very intuitive and a quick win for newcomers looking for results.

27182818284 13y ago

if you go with django, then in the long term, you will have to replace almost every single component of django with something else, the only remaining part will be the url mapper. That has been exactly my experience with a project and it has eaten a lot of time It is the single reason why I'm abandoning Django. Batteries are included, but they are Double DD batteries when I need AA, AAA, etc, etc.

debrice 13y ago
Same here, the remaining is the URL mapper... which I really dislike BTW.
Spiritus 13y ago
I feel the other way around, granted I've played around with Django more than Flask. But the first thing I do when creating a Flask app is pretty much pip installing a bunch of packages to cover the basic functionality Django already provides like an ORM, forms, admin etc.
- 27182818284 13y ago
  For what it is worth, I think Django just needs to be updated in a sense. For example, instead of just form.as_p and form.as_table, they should have form.as_bootstrap which you can do separately anyway, but of course that makes it a separate other thing that I need to reach for.

bkeating 13y ago

This last past year, at DjangoCon US • Chicago, I had the pleasure of sitting at the same table as Jacob Kaplan-Moss for the Speakers dinner prior to the conference. Very cool experience. My first. I brought up Flask and asked him what he thought of it. I had recently used it for a project for the first time and likely only did so because I was SUPPOSE TO BE FOCUSING on Django and preparing a talk about it. So naturally, I procrasinated and did everything but. It's been on my radar for awhile. I was attracted to it by it's documentation. Turns out, I really enjoyed it. It felt familiar because I've used Django for so long. I brought this up at the dinner table. Jacob said something that took me by surprise. I can't quote him exactly--the wine and drinks were too good that evening, but it was something to the effect of "Flask is what Django should have been". Another fellow from our table chimed in and added "If only Django had existed before we created Django!" What he ment was, without Django, Flask wouldn't of had such a clear and smooth start. Django taught us a lot. What I took from this was, both have their place and we have a lot to be thankful for, especially coming from the Django community. In regards to longevity, I think community is a major factor but these two technolgoies are both under Python, and I think the Python community at-large is what matters here. Hearing what Jacob had to say on Flask was sobering. There is no end-all-be-all, and both of these technolgoies have more in common than not.

timtadh 13y ago

I wish the pyramid project, http://docs.pylonsproject.org/projects/pyramid/en/latest/ http://docs.pylonsproject.org/projects/pyramid/en/latest/ , would get some more love in the larger community. It is a really great python web framework which gets a lot of things right and is easy to extend and customize. It doesn't enforce specific project layouts but is still easy setup and get going. I have used it now on 3 projects and they have all been very successful. edit: some background on pyramid's design: http://docs.pylonsproject.org/projects/pyramid/en/latest/designdefense.html http://docs.pylonsproject.org/projects/pyramid/en/latest/des...

Spiritus 13y ago

I've mostly been doing Django stuff. But I had a really hard time scaling my Flask app beyond a single file, I just didn't get how to structure my code.

mercurial 13y ago
When I first read about Django's documentation, I found its notion of "apps" brilliant. It turns out that Flask introduced blueprints a while ago: http://flask.pocoo.org/docs/blueprints/ http://flask.pocoo.org/docs/blueprints/ Like the rest of Flask, it's well thought-out and flexible.

TYPE_FASTER 13y ago

ORM - you'll write a little more code with Flask + SQLAlchemy to get the same result as using the Django ORM. With Flask, you'll have the flexibility of being able to, say, change a repository implementation to use NoSQL for some set of your models. Authentication - Django provides UIs that you can skin/replace, and there are Django applications to do OAuth for you. With Flask there are plugins, you have to provide a UI (and UI workflow). For almost everything Django can do, there is Flask plugin. You might be able to put together simple sites faster with Django, you will get more flexibility with Flask.

youngrok 13y ago

Well, I don't think the choice of framework matters for a large project. What matters is the language, and both use python. Frameworks are only starting point. When you build a large software, there would be many things that framework cannot cover up. No matter how frameworks organize parts of a large software, it's not enough. You should organize by python way, not by django way or flask way. Django app concept? It's good, but what if a single app grows too big? Split two apps? Then what if a project has hundreds apps? We should break down with python modules and packages for a large software. Flask is simple, and it's good for beginners. But is the simplicity helpful for a long-term project? It saves only learning curve of first week. Django supports many features and that's also good, but it only saves time to develop the features. Because flask already supports a lot, the saved time would not be much for a long-term project. Django or Flask matters only for small projects, such as one month long. The choice doesn't matter for a large project. Yes, django template sucks, but you can change to mako or jinja or something else. You like django ORM? That's a good news, but even if you don't like it, you can use SQLAlchemy in django. Such changes can be wastes of time for short-term project, but no problem for large projects. Code pythonic. That's the answer.