
Django vs. Flask for a long-term project - notastartup
http://stackoverflow.com/questions/3005319/django-vs-flask-for-a-long-term-project/
======
rtpg
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.

~~~
hcarvalhoalves
Interesting. Having worked with Django for 5 years, I find the ORM is the
weakest component. There's no way to express trivial things like a GROUP BY
clause, and falling back to raw SQL goes downhill fast, because the result
object doesn't have an interface compatible with Queryset.

~~~
lhc-
Ive actually found the annotate framework can do most primitive GROUP BY
queries (and in the next release or two will gain a lot more power, as its a
big focus). Additionally, many of the other weird queries I need can be
expresset with the queryset.extra() command, which means I get to keep working
with querysets. All this support is only a few versions old though, so 5 years
ago it definitely was much worse.

------
Daishiman
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.

~~~
rmrfrmrf
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
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.

~~~
TylerE
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
How?

~~~
TylerE
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.

------
nkuttler
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
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.

------
bkeating
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.

------
27182818284

        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.

~~~
Spiritus
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
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.

------
metaphorm
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.

------
raverbashing
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.

------
timtadh
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/des...](http://docs.pylonsproject.org/projects/pyramid/en/latest/designdefense.html)

------
eitland
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"

~~~
astrodust
That's the Discourse demo site. What's wrong with resetting it every day?

------
youngrok
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.

------
thruflo
> 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/nar...](http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introduction.html#what-
makes-pyramid-unique)

------
detroitcoder
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.

------
collyw
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.

~~~
sophacles
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
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
I would say that learning the full framework also has the advantages, that

A) It works together. The framework is a framework as a whole, so you can
expect all the components to work together, without having to fudge things, or
crate workaround for things that don't want to play nicely together.

B) There should be some consistency in the components and the way they are
used. That should theoretically lower the cognitive load, if that's the
"bloated" that people are complaining about.

------
TYPE_FASTER
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.

------
Spiritus
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
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.

