gophering on
HN Gopher Feed (2017-07-03) - page 1 of 10
Django vs. Flask
140 points by git-pull
smoe - 3 hours ago
I like both of them a lot for different reasons:If I build a more
generic web application that will include most of their typical
features I'd go with Django. If it is more of an one purpose API
type of project or solving a very domain specific problem it would
be Flask.Django gets your out of the door quickly and there are
extensions for anything I've ever needed, but it can get in your
way later on. If you have to go against its opinions  or if you
need to actually understand what it does under the hood. E.g. file
upload goes trough several hundreds of lines of code if I remember
correctly. Most of it probably doesn't apply to your project, but
you need to understand it anyway.Flask projects are also super
quick for simple projects, but if it is something more elaborate
you really have to spent the extra time setup the architecture
accordingly from the get go, otherwise it very easily becomes a big
unmaintainable mess.My experience is mostly b2b products and
projects, so scalability is less of an issue for me.
sparkling - 3 hours ago
I love and use both frameworks on a daily basis.For tiny
applications: go with Flask.For medium and big applications: it
depends.Flask is great since you can mix and match different parts
from the toolbox and build/use exactly what you want. But it is
easy to end up at a point where you are just rewriting your own
mini-Django on top of Flask.Django on the other hand brings a full
meal to the table. Using other toys from the toolbox is certainly
possible, but it feels "wrong". And yes, Django certainly has some
rough/not-so-shiny edges here and there, partly due to legacy code
that cant be easily refactored due to compatibility. But overall it
gets the job done and it gets polished more with every release.At
the end of the day, it comes down to personal preference.
stanislavb - 43 minutes ago
And here they are some specific numbers on the topic of "Django" VS
"Flask" . Flask
is supposed to have a better code base?
osullivj - 2 hours ago
No mention of web sockets or asynchrony? Fifteen years ago I was
coding against Zope. I've used Django a fair bit too. Both were
heavyweight, blot-out-the-sun one-way-to-do-it. Now I use Tornado
because it's lightweight, has good web socket support and embraces
the async style. It's a joy to code Tornado coroutines with
RethinkDB. If you thought Twisted was cool, but couldn't hack the
learning curve, Tornado is the answer.
acconrad - 34 minutes ago
Seems to me that an accurate analogy is Rails:Django::Sinatra:Flask
smaili - 29 minutes ago
For the python web folks, what web server do you tend to put in
front of your Django/Flask apps and how do you typically deploy new
updates with zero downtime?
  mvid - 19 minutes ago
  Nginx is the one I see the most these days.Having multiple
  instances behind a reverse proxy allows you to do rolling
  deploys, which will have no downtime.
ris - 3 hours ago
So having used both, this is what I tend to say about them: some of
Flask's commonly-used components are better than django's
(SQLAlchemy notably), but altogether, django is a better
framework.I strongly disagree with the notion expressed by some
that beginners should start with flask "to learn how things work".
Making a sane and maintainable project layout is not a particularly
easy thing to do, >90% of people (not just beginners) will
generally fuck it up somehow and end up living with a really weird
app initialization routine as a result. Django's project/app layout
and initialization is really quite well considered and I would say
appropriate for 99% of projects. That 1% would probably be better
off with flask.More broadly, this is the whole opinionated vs. non-
opinionated debate, and I've come to the belief that the vast
majority of programmers need the guidance that an opinionated
framework gives. It is said that flask doesn't try to suggest any
particular structure for your project, but I would say that the
effect of that the majority of the time is to produce a project
with no structure. Don't get me started on the pattern of
`` files everywhere: I mean - what isn't a helper? What
doesn't fall into that category? So yeah, just heap everything and
god knows what in that file.It shouldn't be a shock to you by this
point if I say that I don't think flask is particularly well
designed either, but I won't go into my interface-by-interface rant
  njharman - 1 hours ago
  I agree about Flash/Django. But SQLAlchemy is definitely not
  "better".  It is more powerful, more correct, more proper, more
  flexible. But boy is it a fucking obtuse, verbose, difficult
  piece of bahoo to use. Django ORM follows Django's philosophy of
  pragmatism. Assume sane defaults/be opinionated. Make the easy,
  everyday shit easy!  The hard stuff can be figured out later (or
  just drop to raw SQL).  SQLAlchemy's philosophy is to be correct,
  like RDBMA academic correct and proper.  Make the insanely rare
  and/or difficult stuff possible even if it means making the
  common stuff a PITA.It's like the difference between an esoteric
  and powerful language like Haskell which is objectively more
  correct. And Python, which is "who cares purity, it lets me get
  shit done fast and easy."There's also, I think, a huge divide in
  the way developers think/reason about problems. Cause I've never
  seen anyone like both ORMs. Everyone likes/tolerates one and
  hates the other. I'm guessing some devs "think" the way
  SQLAlchemy works and others "think" the way DjangoORM works.So, I
  do think both ORMs have their place.  Just wish SQLAlchemy's
  place was not in code I have to write/maintain.
    milin - 35 minutes ago
    Fancy seeing you here njharman. And yeah I am working with a
    Sqlalchemy codebase right now, and it really really makes me
    miss django orm.
    scrollaway - 1 hours ago
    I like both ORMs, exactly for the reasons you mention. I wish
    SQLalchemy had a "simple" mode that resembles the Django orm
    API though yeah.
      ris - 46 minutes ago
      I'd wager it would be possible to implement the django ORM on
      top of SQLAlchemy.
    vosper - 1 hours ago
    I'm in the camp of liking SQLAlchemy, and not really liking
    Django's ORM, which I am admittedly much less familiar with. I
    especially find Django's functionality for aggregations to be
    completely arcane and a long way from the SQL that I am
    modeling in my head. I wonder if that's what it comes down to -
    as someone who tends to think in terms of the SQL I want to
    build I find SQLAlchemy to be a lot closer to my mental model
    than Django.For just getting an object by ID I don't think
    there's much difference, for me.I think one thing in Django's
    favour is that SQLAlchemy can be confusing to setup (do I need
    scoped sessions?). Also, you need to find and setup your own
    solution for migrations, whereas Django will just sort that out
    for you. So getting up and running is a lot easier.
    ris - 49 minutes ago
    > But SQLAlchemy is definitely not "better". It is more
    powerful, more correct, more proper, more flexible.Indeed - for
    my purposes, it's better. But I loves me' databases.> And
    Python, which is "who cares purity, it lets me get shit done
    fast and easy."Oh - ouch. It is possible to write quite pure
    python, y'know. But it allows you to break the rules when
    purity would just lead you down very obtuse paths. Or when your
    code is fundamentally side-effecty.
  aaron-lebo - 2 hours ago
  What about Django makes you feel it is the better framework? It's
  a great singular package, but basically everything in it is done
  better somewhere else. I'd take Flask's templates over Django's
  any day and Peewee or SQLA over Django's ORM as well. I never
  liked regexs for routing and as I've gotten older and liked
  regexs more, still don't like that approach - Flask's approach is
  better.Django is nice for beginners cause you can say "learn
  this" and they've got a bunch of books and docs to go through,
  but having watched Django evolve over the last decade, it hasn't
  really changed from it's stable but boring and does nothing best
  manner.They're both kind of dead tech anyway given enough time.
  Python isn't the best choice for today's websites. That being
  said, don't know what language/framework is the right thing to
  push on a beginner.
    sametmax - 2 hours ago
    Integration, documentation and ecosystem. And together, weight
    heavily in the balance.
      ris - 24 minutes ago
      This.If I tell someone to go away and write me a project in
      flask or a project in django, provided they "go with the
      flow", the django one will almost always be nicer. A sensible
      `` interface. Apps that can be built to be
      installable, read-only python packages rather than "here's a
      project repo, clone it, cd into it and run ./".It
      is of course possible to design such a project in flask, but
      it takes some work. The gravity is strongly towards "I am the
      world" projects.I've also been very surprised at how much
      less community support there seems to be for flask. Googling
      /StackOverflow-ing an issue has tended to get me
      significantly fewer results, and of those results I do get
      far fewer of them seem to have (sensible) answers. In the
      django world there is a much broader coverage of generally-
      accepted sensible ways of doing slightly obscure things.
  crdoconnor - 2 hours ago
  >More broadly, this is the whole opinionated vs. non-opinionated
  debate, and I've come to the belief that the vast majority of
  programmers need the guidance that an opinionated framework
  gives.The vast majority of programmers need opinionated because
  they want to string together 15 or 20 different plugins to do
  ordinary things like CMS, rate limiting, caching, facebook/github
  authentication, csv export from the admin, drag and drop within
  admin, and hundreds of other things where you don't want to
  reinvent the wheel.With Django there is a larger ecosystem and
  those modules tend to play better together, and they are pretty
  much equally loosely coupled. With Flask you get a few modules
  that use SQLAlchemy, some that use peewee and others like Quokka
  (flask CMS) that just decided to use mongo for the hell of it.
  That's the dark side of not being opinionated.The "batteries
  included" argument is a red herring, IMO. It doesn't really
  matter that Django includes admin in the 'django' package and
  flask separates it out into 'flask-admin'. You don't have to use
  either if you don't want and being in a different package is
  orthogonal to coupling.The magic argument is also sometimes a bit
  of a red herring too. SQLAlchemy, django ORM, django admin and
  flask admin all use tons of magic but everybody loves them. Magic
  is horrible in the wrong place but incredibly powerful in the
  right place. Rails gave it a bad rep because it used magic too
  much in the wrong places.
  rifung - 1 hours ago
  > I strongly disagree with the notion expressed by some that
  beginners should start with flask "to learn how things work".
  Making a sane and maintainable project layout is not a
  particularly easy thing to do, >90% of people (not just
  beginners) will generally fuck it up somehow and end up living
  with a really weird app initialization routine as a result.
  Django's project/app layout and initialization is really quite
  well considered and I would say appropriate for 99% of projects.
  That 1% would probably be better off with flask.I actually feel
  like this is why I recommend beginners start with Flask though. I
  think learning the mistakes and seeing the problems and pain
  firsthand let's you appreciate and hopefully understand the
  decisions that were made.Of course, I should say I recommend it
  for something like a toy project that you don't intend to
  maintain. If it's something that's long term then I would agree
  that Django is likely to be the better choice.In the end I
  suppose everyone is different in the same way some people
  recommend learning Python vs C as their first language.
    ris - 44 minutes ago
    > I think learning the mistakes and seeing the problems and
    pain firsthand let's you appreciate and hopefully understand
    the decisions that were made.In my experience, people just
    don't. They just continue on oblivious thinking nasty code is
    just part of life. I think I'm lucky having gone to django
    first so that I'm able to see that things don't have to be
  sametmax - 2 hours ago
  > So having used both, this is what I tend to say about them:
  some of Flask's commonly-used components are better than django's
  (SQLAlchemy notably), but altogether, django is a better
  framework.Most Flask dev however, are unable to leverage the full
  power of SQLalchemy. They do miss the nice integration of the
  Django ORM, espacially the form generation, admin and fantastic
  app ecosystem that assumes you have a User object.> Making a sane
  and maintainable project layout is not a particularly easy thing
  to do+1000 on this. I noticed this as a dev AND a trainer. In the
  end, flask is great if you are either very beginer and want to do
  simple things, or very experienced. For all the rest, you want
  Django.But the price to pay to enter the Django world is higher.>
  It shouldn't be a shock to you by this point if I say that I
  don't think flask is particularly well designed either, but I
  won't go into my interface-by-interface rant now...Well, the
  global objects such as request is one of my pet peeve... And the
  decision of a central "app" object make modularity kinda
  difficult, and blueprint feel like afterthoughts.But flask also
  almost invented the whole @route API, which is really awesome.
    ris - 41 minutes ago
    > But flask also almost invented the whole @route API, which is
    really awesome.-1000 on this. It's a side-effect-on-import
    nightmare. Not to mention scattering your url scheme all over
    your view modules makes it much harder to spot where your
    scheme doesn't make sense.In my opinion.
  plandis - 1 hours ago
  That makes sense about project organization done correctly.The
  thing that really stands out about Flask to me (using it for
  small projects, I don't really get to use Python at my day job)
  is that the codebase is incredibly easy to understand in it's
  entirety. Anytime I have needed to look something up I can go to
  the code and usually understand it within a minute or so.I'd
  classify myself as a mediocre programmer by big tech company
  standards and Flask is very easy for me to understand and use.
    brianwawok - 59 minutes ago
    I would think most Django projects are easy to read also. Part
    of Python generally...
jedberg - 3 hours ago
I feel like Django has too much magic.  I agree that it is easier
to get quick wins with Django, and if you're building a small hobby
site or something, then it's great.But if you're building something
that you hope you'll have to rapidly scale, Django is going to hurt
you.  It's way harder to scale due to both its heavy reliance on
hidden magic its tight integration with its data store.When you
want to rapidly scale, the easiest way to do that is if your data
store and application aren't so tightly intertwined that you have
to scale both to solve a bottleneck in either.
  tuxxy - 3 hours ago
  I completely agree.My favorite framework is Flask, but I have to
  work with Django professionally. I find that using Flask produces
  much cleaner, readable code (depending on the engineer, of
  course).When I'm working with Django code, I find myself opening
  two to four different files just to make a tiny change in some
  restful API. I find myself doing the same just trying to read
  some code or trace down a bug or even a utility function.I find
  that the object oriented nature of Django also tends to produce
  overly complex codebases for the things that people try to
  create. It hides code in favor of magic which just complicates
  the development process.
  ris - 3 hours ago
  > I feel like Django has too much magicAre you kidding? Flask is
  side-effecty module, global-variables, make-sure-you-put-this-
    jedberg - 3 hours ago
    I never said Flask was better...
  askvictor - 1 hours ago
  I also thought it was magic and scary when I started using it.
  Then I got to understand how it all works and it's no longer
  magic, just python.
  Veratyr - 3 hours ago
  As someone who's worked on a moderately large Django project, I
  have to disagree. There's a lot of stuff done for you without you
  seeing it (like Admin and the default QuerySets + Managers) but
  it's fairly easy to understand, customize or debug if you want to
  and Django's source code is actually really readable.Plus, Django
  has some of the best software documentation I've ever seen. It
  was incredibly rare that I couldn't find an answer to how/why
  something worked in the docs.
  ceyhunkazel - 2 hours ago
  Scalability problem is the nicest thing that can happen to you
  which means you are successful. Short time to market and low
  budget  are the common cases for startups. If you have money and
  time then you can more worry about scalability issues and all
  generalizations are false, including this one.
  orf - 3 hours ago
  Django has a lot less magic than Flask. Flask has thread-local
  global request objects for example, among other things. Under the
  hood Django is quite explicit in how it works.What examples of
  magic do you have, specifically?
    Walkman - 1 hours ago
    Django has hidden thread locals, Flask makes them explicit, so
    a lot less magic.
  git-pull - 3 hours ago
  Django does have magic:The key thing is Django's implicit
  behavior is directly proportional to the job it's trying to do
  [1]:- Django's settings can be invoked at any time. So it's kept
  as a lazily-loaded singleton that isn't processed until an
  attribute is first accessed.- Django needs to know which apps to
  load (a la INSTALLED_APPS). And to know the models, django needs
  to know the apps. These app models can contain relationship
  dependencies, so its necessarily from a invocation perspective to
  have a settings that declare them all.- Using Django's
  initialization is a must. For the reasons above (settings), but
  there is work done behind the scenes to make sure everything
  lines up when Django starts.- It's most likely project's using
  Django are going to be using it's ORM.On the other hand:- Django
  doesn't hold every project, or every request for that matter, to
  its batteries. Intricacies like middleware and context processors
  are opt-in. Things like template filters are also opt-in on a
  per-file basis via {% load %} tags.- Whether or not to use Forms
  Framework / crispy-forms, for instance, is optional. But projects
  would miss out on nicely generated forms with validation.-
  Projects can also switch out template engines for Jinja2 or
  something totally custom.- While strictly speaking, projects can
  just keep empty, QuerySet's are like the ultimate
  reusable interface in Django's  Frameworks. QuerySet's can be
  used:  - by class-based views (CBV)   - ModelForms to provide
  database-backed form validation   - by third party extensions
  like Django REST Framework (DRF), django-filter, django-tables2,
  django-guardian, and so on   - in context processors (which can
  access URL regex group matches), that later are passed into in
  templates.      While that may feel like overkill, this is useful
  for things like database-backed menus that CMS like Drupal and
  WordPress would use by default.  > It's way harder to scale due
  to both its heavy reliance on hidden magic its tight integration
  with its data store.I plan on making a future article diving into
  Django's ORM. Sure, ORM's hide a lot of machinery behind a facade
  of sugary objects. But on most web projects the database's aren't
  doing much more than simple joins.Django's ORM can scale into
  medium-sized code bases. By the time it gets beyond the point the
  ORM can handle, heavier data tools (like ElasticSearch, Hadoop)
  would end up being brought in regardless of whether Django was
  picked. That doesn't mean earlier code or data schemas need to be
  thrown out.Put it another way: When project's get to the point
  they need a datamart or other things, they're likely to create a
  separate service for that distinctive from the web front-end.[1] /
  sametmax - 2 hours ago
  Na, I built a video streaming website with django. It has 400 000
  v/d.The team now working on it is not very gifted, and yet they
  manage to make it evolve because Django makes it easy.
  coldtea - 3 hours ago
  >But if you're building something that you hope you'll have to
  rapidly scale, Django is going to hurt you. It's way harder to
  scale due to both its heavy reliance on hidden magic its tight
  integration with its data store.Considering that Django has 1/5th
  as much "magic" as Rails, and that Rails powers some of the
  biggest websites on the world, I'd say "citation needed".
    a3n - 1 hours ago
    What is "magic,' and how do you measure it so that you can say
    things like "1/5?"
    jrs95 - 3 hours ago
    And Django powers some huge sites as well. IMO the magic
    doesn't really hurt you there as long as your still working
    with a relatively monolithic piece of software.
    Steeeve - 3 hours ago
    What besides reddit?
      Jugurtha - 2 hours ago
      I believe, too, is built on Django[0].Also, here's
      an interesting thread on Artima: "Please Teach me Web
      Frameworks for Python!"[1] by Guido van van Rossum[sic]. It's
      11 years old (a lot has changed since?), but interesting.[0]:[1]:
      147 - 3 hours ago
      Reddit isn't powered by Django as far as I know. But
      Instagram is and I believe Pinterest was/is.
        codefreakxff - 3 hours ago
        Nov 2016
          CCing - 2 hours ago
          Backend is still django though
          sthatipamala - 2 hours ago
          The Pinterest web backend has some vestiges of Django for
          form validations and stuff, but IIRC it's mostly custom
          at this point.
      flunhat - 3 hours ago
      Instagram is one, I'm sure there's others [1].[1]
      Veratyr - 3 hours ago
      Reddit is Pylons based. Instagram is Django though.
      dom0 - 3 hours ago
      Reddit uses Pylons iircBut see for yourself:
        Steeeve - 3 hours ago
        Interesting.  Looking around because I thought it was ruby
        at one point, but it turns out it was originally written in
        Lisp. don't
        know where I got that idea from.
        agumonkey - 2 hours ago
        And they blogged about moving to typescript for frontend at
      wyc - 3 hours ago
      Kept a small list here, including codebase changes made for
      scaling and references:
      it-in-django-or-rails/Instagram, Disqus, Bitbucket,
      Pinterest.Apologies in advanced for any marketing copies you
      don't want to read. The information is there.
      danso - 1 hours ago
      PyCon's keynote this year was given by Instagram:
      brynedwards - 3 hours ago
      There is a list at the bottom of this page:    Disqus
      Instagram     Knight Foundation     MacArthur Foundation
      Mozilla     National Geographic     Open Knowledge Foundation
      Pinterest     Open Stack
        yen223 - 1 hours ago
        If the answer here is to be believed, Pinterest has
        consciously moved away from Django.
  zimablue - 3 hours ago
  Which parts are you referring to as magic, the models? I use DRF
  and find the way it deals with defaults quite nice, your can use
  a model and it will generate fields or not, and specify or
  generate them yourself.
    jedberg - 3 hours ago
    Mostly the ORM.  If you rely on it, you can't really lay out
    your tables in any way except the way they do it, at least not
    without a whole lot of headache.
      njharman - 1 hours ago
      It requires you have a primary key. That's it.Everything else
      table names, fk's, multiple databases, etc. is overridable.
      The only thing I know of that is a slight headache is
      postgresql namespaces (aka schemas).Django does make choices
      for you. But almost everyone of those choices can be
      overridden. I have found that most people who think Django
      (or any large/mature/widely used project) can't to something
      is because they don't know it well enough.
  nine_k - 1 hours ago
  Django uses "magic" (mostly in the form of "convention over
  configuration") to make certain approaches simpler. It also makes
  other approaches, not planned for by the framework, harder.This
  is why Django is great for a particular kind of sites, and not as
  great for other kinds. "Originally designed for the newsroom", as
  they note on their site; it still feels.As it's typical with
  frameworks, Django helps you as long as you do things "the Django
  way", and does not help, or counteracts you, if your problem
  domain does not fit well into Django's.I suspect it's the case
  with any reasonably specific tool. A hammer is damn efficient as
  long as you have to deal with nails, and a wrench is great for
  nuts and bolts ? but neither is going to help you to assemble an
  electronic device. Choosing the right tool for the job is as
  important as always.Django, on the other hand, is not a tool, but
  a toolset ("framework"). Replacing any tool in it is not
  impossible but loses some of the affordances of the original
  custom-adjusted tool. I used SQLAlchemy with Django, and it
  definitely can be done, but you lose e.g. automatic admin pages.
  I had to go to immense lengths to change the way settings
  initialization works in Django  when I had to update some of them
  after `import settings`.Flask is a more loosely coupled bunch of
  tools. E.g. SQLAlchemy is an entirely separate project, just
  adopted to work in Flask with a custom layer. From the point of
  view of long-term development, it's better, it's more flexible.
  From the POV of a rapid prorotyping of a typical CRUD app, Django
  is better because it's more integrated. It will bite later, but
  at the start, most people are ready to make technical debt in
  exchange for velocity.
    RUG3Y - 48 minutes ago
    I'm currently working on rebuilding a fairly large Django app
    in Flask. My situation is exactly what you describe, the use
    case is not one which Django is really built to accomplish. The
    result is lots of difficulty dealing with the data. I feel like
    Django is great if you're building content driven websites. Our
    website barely scratches the surface of our application, and
    the Django backend has become very.
  dom0 - 3 hours ago
  Django's magic and some really "Unpythonic" implementations of
  magic are mostly annoying when you're trying to use it in any
  context other than serving exactly one webapp over HTTP per
  process.(Unrelated blurb:) Pyramid's design contains a lot of
  wisdom; some folks working on it have been doing Python web
  frameworks since the web came into existence.
drawkbox - 2 hours ago
Flask is still one of my favorites in web frameworks, mainly
because it was from the Sinatra/microframework moment and still is
a pleasure to work with. Just plugin other micro frameworks for the
data, middleware, routing, templating as desired.Express is similar
in Node still because of the simplicity and micro size of it.Micro
frameworks don't dictate and grow with a product as needed rather
than growing into a monolith and it dictating too much.As far as
Django, it is still one of the most desirable monoliths out there
but you don't have to use it that way. However, it is meant to take
over like Angular, Rails, MVC etc.
timwaagh - 13 minutes ago
I worked with flask once. It was code made by an obviously gifted
russian coder i worked with. Cleanest webcode i have seen. I never
played with django, all i can say is flask can produce really clean
gshulegaard - 13 minutes ago
I think both Django and Flask are good frameworks that solve
different problems.  Django has a batteries included philosophy
that gets you up and running quickly without ever leaving Python
(as the developer).  Flask is drastically less opinionated and
focuses on providing you web hooks to bring your project/logic to
the web letting you do whatever you need behind the
scenes.Personally, I feel like Django is great for a "traditional"
and straightforward web applications and Flask is better for
projects that may require a bit more flexibility both in modeling
and backing services.I think this line from the article follows
this perspective:> Before long, projects will be dealing with
forms, REST endpoints and other things that are all best
represented via a declarative model with types. The exact stance
Django?s applications take from the beginning.
jordic - 3 hours ago
On my next side project will use pyramid  next aiohttp or tornado.
Python has a good ecosystem of libs. Pick one when you need it.
Django is perhaps the less pythonic  option. After some time doing
go and js.. I prefer the lib approach.. on the end you don't need
so many things to quickly respond to http requests ;)
  osullivj - 2 hours ago
  I started out with Zope 15 yrs ago, then switched to Django. Now
  I use Tornado for it's support for web sockets and an async
  programming style. Tornado coroutines work beautifully with
    jordic - 2 hours ago
    I discovered zope some months ago and I really must say that is
    impressive. Once you get the ZCA and the object publishing is
    really easy to build things. Zodb is also a good tool! Plone
    has a good and rich ecosystem and as a CMS is far a way better
    than all django based ones... There is a lot of things outside
    django and flask...
  veeti - 3 hours ago
  Pyramid really is the underappreciated hidden gem in Python web
  development. It can be as much of an micro- or full stack
  framework as you need it to be, while being much better thought
  out and extensible than something like Flask or Bottle.No crazy
  thread local state imports to complicate testing and encourage
  people to couple their code to the web framework, features like
  renderers to make _unit_ testing view functions easy, almost 100%
  test coverage in all the core libraries...It's a shame that the
  mainstream basically boils down to Django or Flask. But it's no
  wonder that organizations like Mozilla and new PyPi are building
  on Pyramid instead.
Steeeve - 3 hours ago
I always saw it as Django is the lady with the 30 pound purse that
has everything you could possibly need on a trip to disneyland and
Flask was the guy who showed up to the camping trip wondering why
everybody else brought a tent when it's so nice out.
  matt_wulfeck - 3 hours ago
  Django is the camper with the U-Haul. Flask is the camper with
  the backpack. Bottle is the camper with the fanny pack.
    type0 - 3 hours ago
    I like bottle, also I like fanny packs.
    tedmiston - 1 hours ago
    I wonder how Falcon fits in here.
      matt_wulfeck - 1 hours ago
      The focus seems to be on performance, so my guess is they're
      the camper with a fanny pack but it's already unzipped.
        dguaraglia - 19 minutes ago
        Haha, that cracked me up!
    SimbaOnSteroids - 1 hours ago
    Who's Bear Grylls then?
      dagw - 1 hours ago
        import socket
  hetspookjee - 3 hours ago
  I believe that is the general consensus.
yen223 - 52 minutes ago
I'm working with a large, 5 year old Django codebase. My humble
opinion: Django itself is actively hindering our ability to deliver
new features.Some pain points:- Django's fat models approach is
bad. By coupling model behaviour to database schema, it all but
guarantees that you're gonna have a tough time modifying either.-
Django's class-based views and its admin framework strongly
encourages a sort of "one-view, one-model" approach. Just about
nobody has requirements that neatly fit that worldview. If you need
to interact with two models in a single view, working around it is
painful.- Not Django specific, but Python is a bad choice to use at
scale. The lack of a good default immutable data structure means
we're stuck using mutable data structures everywhere. In a large
codebase, the lack of guarantees around something as basic as the
shape of a data structure is a huge problem. A notorious example is
Django's HttpRequest, whose attributes may or may not be set by the
middlewares.There are more, but one thing's for sure, I probably
won't be using Django for my next project.
brango - 2 hours ago
If you need user authentication use django. If it's for APIs  use
flask or gRPC.
  CuriouslyC - 2 hours ago
  I found Flask-user to be pain free.  This is important because
  almost all applications need some form of persistent user data.At
  this point I wouldn't use suggest Django for anything other than
  a straightforward server-rendered crud app, particularly if the
  developers are less skilled.
nthcolumn - 2 hours ago
One of these things is not like the other. You don't have to choose
and there will be cases for both where one is the vastly superior
choice. For example: I'd go with Flask for microservices but django
for a CMS. I'm sure some people will argue the more apposite. The
nodejs thing is so fragmented and difficult by comparison. Flask's
routes are better. django's admin absolutely rocks (still). I guess
these face-offs are fun but I don't find them very informative,
relevant or meaningful. A weird hybrid though - now that would be
cool. Or a SAP killer in django.