Django vs. Flask

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.

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

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

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.

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.

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

I was never able to do what I wanted to do in Django. The moment you have something that even slightly breaks apart from the MVC model, it all breaks down. It's great for a blog or simple web app, but not much more than that.

In Django I always felt like I had to do things the Django way. In Flask I always felt like I was doing things the Python way.

> 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

For help with this: https://www.starterkit.win/

> >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app

tbh I've seen this plenty of times regardless of whichever framework people choose. At least with Flask the original developer sometimes gets a twinge of 'hmm this seems like a lot of work & might be a mistake'; Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB (+the associated invalidation bugs).

Do you think Flask would be any better a choice for a smaller project?

> 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 blame Flask, blame whoever hired mediocre developers in your company. No framework that "enforces" things will compensate for bad​ human capital.

I would have to agree with you, there's no point in learning Flask if you're going to do Django projects. Things don't translate well between the two. I like both frameworks, for different things, but you shouldn't try to do a Flask application in Django.

To benefit from Django, you need to do exactly what the documentation want you to do. You'll be happier, everything will be easier and you write a LOT less code. I tried fighting Django, because I didn't agree with some of the design decision, especially in the Django Rest Framework. The result was a worse product, too much and too complex code. The rewritten version did everything "The Django Way". It took less time, and the result was infinitely more understandable and testable.

Django is the camper with the U-Haul. Flask is the camper with the backpack. Bottle is the camper with the fanny pack.

I believe that is the general consensus.

What framework or language would you use to write the same codebase with from scratch?

It won't help you with handling code size so big you really want types, but one advice I would give is ditch class based views. I find that function views much easier to reason about, even if it leads to code duplication. The ability to read the code linearly without jumping through inheritance hierarchies makes everything better.

> Django's fat models approach is bad

while django encourages Fat Models and that approach ends up working well sometimes, django itself has no such approach to models. how much logic to put in a model is left to the application developer.

i think what tends to happen, though, is that coming up with a convention different than Fat Models is difficult, especially early on, so most organizations don't bother and end up with models that are badly abstracted AND fat.

this could be seen as a failure of the django community, but it is not a shortcoming of the framework itself.

I share your sentiment about python in large code bases. I used to think dynamic languages like python/ruby provide superior expressiveness and therefor should be excellent choices no matter what kind of project one is working on.

Now I believe they should only be used for small projects or quick prototypes. Anything beyond that and everything starts getting very confusing.

You can still opt for function-based views almost 100% of the time. Though I'm a big fan of FBVs for "You see what you get", I've started to find that writing your own, project-specific CBVs might pay off for speed + enforcing style in handling requests though.

Fat models are most definitely a pain. Our solution has been to not rely on models for almost anything except for DB interaction, and instead have wrappers that act as business functions. So instead of Post.objects.create, you just write create_post. You still get ORM goodness for the most part, but your validation/creation layer is under control so you can apply your style.

Overall, Django's defaults and even the fat model approach can work really well if you're writing a CMS, for example. And fortunately it's getting easier and easier to use only what you want.

I hear you for the mutability of request objects. Mypy has helped us out a lot, but Django is pretty resistant to those.

I'm a heavy Django user, but I work on a lot of data-intensive projects. I do my data modeling in the database and expose it to Django, and it feels pretty clean to me. I use the ORM for what I would consider its true purpose: converting relations and attributes to objects and properties. I use it very lightly, otherwise, like for filtering and sorting.

* Create primary "fact" models for the things you are CRUDing.

* Process the data in the database. Write your complex operations in SQL, and expose them as views.

* Create corresponding Django models on top of the views. These are not as "fat" because they are unmanaged models that just facilitate getting processed data to the user.

If you're using a good database, you accommodate writes through the views as well. I rarely find a good reason to do this, but when it comes up, it works great. It is especially useful when dealing with legacy schemas.

> The lack of a good default immutable data structure means we're stuck using mutable data structures everywhere.

Don't completely understand this one. Also, couldn't you create an immutable-in-practice class?

The problem with this sort of advice though is that everyone likes to think their project will go hyperscale, or will be prepared to if necessary. The reality is that very very few of them ever need to yet so many design with this is mind not understanding the tradeoffs and what they're losing by following this approach. (Incidentally I also attribute much of the current popularity of microservices to this idea)

The fact is that once you hit hyperscale you should almost certainly not be using the same codebase as when you were still establishing exactly what your project should do.

For most projects, the fat models approach works really very well and I don't feel is something that people should be dissuaded from. For most projects, the alternatives are far harder to get clean results from.

Checkout Keg (https://github.com/level12/keg)

It could use some documentation and some community TLC, but Level 12 is a solid Python shop with a pragmatic approach to app development. There are libraries for auth, login, webgrids, SQLAlchemy, forms, etc etc.

Disclaimer: I used to work for Level 12 and wrote a large production app atop keg.

https://websauna.org ?

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

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.

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.

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.

> I feel like Django has too much magic

Are you kidding? Flask is side-effecty module, global-variables, make-sure-you-put-this-magic-incantation-which-you-dont-understand-in-your-init everywhere.

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.

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?

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 models.py 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] https://www.git-pull.com/code_explorer/django-vs-flask.html#... / https://www.git-pull.com/code_explorer/django-vs-flask.html#...

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.

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.

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.

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.

Ability to "rapidly scale" is an overrated virtue. Scaling is exactly when you should step back and reflect on your architecture, at which point you should understand that very few of your scaling concerns are at the framework level. I continue to be involved with a 2+ million LOC Django site that's been 8 years under continuous development that went from 10+ million users to 100+ million a summer ago. Django was never the issue.

If the particularities of Django are what's in the way of scaling for you, you have bigger issues than Django.

> If you're building something that you hope you'll have to rapidly scale, Django is going to hurt you.

Yet somehow people have built wildly successful companies handling massive amounts of traffic using Django. Yes, many have had to re-architect to scale better, but which company hasn't had to do that as they grow from thousands to millions of daily active users?

This so much. Getting past the "it just magically saves to your db with .save()" by reading the source was critical to my improvement with django.

I find myself doing this more and more often with python libraries, even with the well-documented ones like Django REST Framework - always keep a source browser open on the virtualenv dir so I can read library source. There's something about the style of python documentation that makes it difficult to really understand how the classes in a library fit together, so this is necessary for larger python frameworks.

(My personal gold standard for programmer reference documentation has been the Qt API docs for very, very long. They've varied in quality over the years but they're always an example of how to do it.)

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.

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

Be careful with aiohttp, async io is great, but the actual http parser in aiohttp is super slow.

See https://magic.io/blog/uvloop-blazing-fast-python-networking/ for a full write up.

I've been building stuff in sanic, which is built on uvloop and is super fast. I can recommend it if you're willing to sacrifice a bit of project maturity for a solid async webserver.

My apprehension about using flask for microservices is that calls to another microservices are going to block. With NodeJS, the webserver and http libraries are async and mature. Python's really missing a solid async requests library (but async webservers like sanic are getting better).

Python in general does this. Its designed to be readable first in most regards, something really valuable for other languages to learn - for every line written, it will probably be read dozens of times. Optimizing for the writing part with arcane or convoluted syntax at the expense of legibility only makes projects age poorly.

I've found falcon a real pleasure to work with building pure json APIs, super sane approach to hooks and middleware which makes handling auth and db pooling both explicit and simple. Plus it's pretty fast which is always nice for building a REST API.

Extensions can register themselves with the Flask application object, so you can look there: current_app.extensions['whatever']. However, it is not specified what exactly this dictionary contains, so eg. SQLAlchemy puts a custom State class there. You can still get the extension object out of it, it's just that there is no common convention.

http://flask.pocoo.org/docs/0.12/api/#flask.Flask.extensions

https://github.com/mitsuhiko/flask-sqlalchemy/blob/master/fl...

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.

I currently use Apache with mod_wsgi. New updates involve just touching the .wsgi file. schema changes are a bit more involved obviously.

For a while I did nginx with gunicorn. No downtime rolling deploys. Just need a git pull and the proper kill signal.

Now I use kubernetes with uwsgi. Once you are kubernetes any app server works, so went uwsgi because it is very very simple.

Nginx + Gunicorn is what we use. It has worked great for us. We have also tried uWSGI, a waitress for our production and Nginx + Gunicorn have been sure shot winners in terms of scalability and performance.

This is our gunicorn.conf that ensures gunicorn does not cause memory leaks

    import multiprocessing
    import os
    import random
    from getenv import env

    def pre_fork(server, worker):
       f = '/tmp/app-initialized'
       open(f, 'w').close()

    bind = 'unix:///tmp/nginx.socket'
    workers = os.environ.get('WEB_CONCURRENCY', 
    (multiprocessing.cpu_count() * 1 - 1))

    MAX_GUNICORN_REQUESTS = env('MAX_GUNICORN_REQUESTS', 100)

    if MAX_GUNICORN_REQUESTS:
       max_requests = MAX_GUNICORN_REQUESTS

    MAX_REQUESTS_JITTER = env('MAX_REQUESTS_JITTER', 25)

    if MAX_REQUESTS_JITTER:
        max_requests_jitter = env('MAX_REQUESTS_JITTER', 25)

If you mean in the frontend, AngularJS was going in that direction. Then react came along and the angular developers decided to copy it, in a different language and with even more boilerplate.

I believe nowadays it's ember the one that comes with batteries included, but I haven't used it nor read a lot about it so don't quote me on that.

If you meant the backend, the only one I always hear about is express, but I'm not sure about that one either.

Sails.js is a fill-stack JavaScript framework with similar scope to Django, such as:

- MVC - routing - templating (though, swappable) - ORM

As for maturity, Sails.js has been under active development for around 5 years, with a 1.0 release candidate available.

http://sailsjs.com/

I am interested in your story. Concrete examples would be helpful. Did the team follow a performance improvement mandate, analyzing the Python system and then deciding how best to proceed, or was performance not the primary motivator?

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.