If you're building a complicated, full, user-facing application, and start with Flask, you'll find yourself reinventing most of Django.

Eg, a user model with pluggable authentication and flexible permissions model, ORM with migrations and associated automatic form generation and validation, static asset compression pipeline, CSRF and CORS protection, etc.

Yes, you can find Flask libraries to handle pretty much all of that stuff, but it's on you to pull it all in, glue it together, figure out which ones work well together, and document it for any one else who might work on your project. Especially for some of the security related things, it's definitely nice to know that those parts have been integrated and tested and audited already.

It's a tradeoff. With flask, you can get exactly the components you like; with Django, they're mostly chosen for you. If you don't like Django's ORM, you can replace it, but then you lose a lot of the advantages that come from its integration with everything else.

To extend this a bit, I would consider Flask if I didn't have a relational database. Without a relational DB, you lose the ORM and most of the ecosystem that's tied to it. At that point, something lightweight and simple is appealing.

In practice though, when I've been in that situation, I've found it more compelling to just drop Python and use Go instead. I guess with a use case that relied on NumPy, Pandas, Tensorflow or something Python-specific but that didn't have a UI, I might still go with Flask.

>To extend this a bit, I would consider Flask if I didn't have a relational database.

Use the Flask-SQLAlchemy plugin. It works beautifully. SQLAlchemy is a very good ORM.

Did you read my original comment? My point was that if you're using Flask, you are responsible for pulling in all of those components and making sure they work together, not that there weren't good components available for Flask. I'd rather use Django if I need all of those things and want them to work together. If you don't have a relational database, Django's ecosystem advantage (much of which hinges on the ORM) isn't as strong and Flask becomes worth looking at again.

The "Flask-sqlalchemy" plugin, as its name implies, makes Flask and SQLAlchemy work together just fine.

Ecosystem aside, who do you think has better ORM concepts: Django or SQLAlchemy?

I haven't really used SQLAlchemy in anger since about 2009. I remember it being fine but I can't really say much else about it. That said, I haven't run into any limitations of the Django ORM that have driven me to look at other ones.

Exactly this. Every production Flask project I've seen has a massive requirements file to bolt on functionality that comes built into Django. The second I realize that I need an auth system or may potentially have a DB migration, I select Django.

Frankly, I don't see the attraction to _bring your own_ frameworks in most cases (though I've done it for very specialized cases). I get paid to get projects done, not to reinvent the wheel.

Built in everything. Users, auth, admin, ORM.

Flask is the opposite: Bring Your Own Everything. It's not hard to replicate the functionality of Django but there is surely utility in having everything boxed up and ready to go.

Never use the built in user. Always start a project with a custom user extending abstract user.

At some point you'll want to customize the user in some way (like making the username case insensitive), and you don't want to be dealing with migration dependency conflicts when you do.

For some reason the Django team is really against any attempt to fix that. They're almost hostile in their discussion of it.

OK. Well, I've been building Django apps since around 2007/2008. More than 50 deployed to production, many still running/maintained. Never once had a problem using the built-in user model. Do you work in some vertical that makes this a particularly common problem for you?

I don't think the parent comment is saying don't use the built-in user model. The comment is suggesting to sub-class/extend the built-in user model. So you can use much of the built-in functionality and add/change what you'd like, eg. to add a birthday field

There are obviously other ways to do this, perhaps by creating a Profile model that relates to a User.

Yes. Technically you should extend the abstract user model or things get real broken real fast, but that still gives you all the functionality of the built-in user model right out the gate.

The main reason is that if you ever want to change how the username works, it will be a major pain to do if you've been using the built-in user model and already run migrations.

You've never had to extend the user model? I suppose you could just do most extension with a model that has a 1-to-1 with users and use a proxy of the built-in model for the rest, but it seems much simpler to just start out with a user model you can customize easily.

I create Profile's that are mapped 1-to-1 to django.contrib.auth.models.User all the time to hold additional fields. I consider that the "orthodox" approach that Django encourages.

I've even implemented "case-insensitive username" a time or two, but done it by overriding some logic in the login view rather than modifying the user model.

That seems like a lot of trouble when you can just start out a project with a few lines of code extending abstract user. The case-insensitive username can then just be done by making the username a case-insensitive text field (admittedly only available in Postgres, but that's true for a lot of awesome Django features).

I don't mean to be mean, but your answer reminded me a lot of the last row of this comic: http://www.giantitp.com/comics/oots0050.html

But you see, I find that overriding the one little bit of view code (literally a couple lines of code) to change the one thing I want changed is by far the simpler approach rather than changing the whole structure of the user model and introducing who knows what kinds of subtle bugs elsewhere. When the requirement for "case-insensitive username" comes in, it's always turned out that all they really mean is "If someone types 'Bob' in the username field rather than 'bob', it should still work". And again, even that has been such a rare thing that I've probably spent more time writing this comment here than implementing it in code, so why overcomplicate it?

If you change login and forget to change registration, suddenly "Bob" can't login because "bob" just signed up for the service and your login is now returning 2 users. Django puts username validation on the model field for a reason. It's better to have it all centralized.

The nice part about extending the abstract user from the start is that you can still just use it exactly like you'd use the built in user. There's no difference. It just gives you more options in the future.

It literally only takes 8 lines of code, including imports and a "pass" to do.

Heh, wish I'd done this back in 2012 with my app. Admittedly it wasn't as easy to do back then IIRC.

Now one of my to-do-one-day jobs is rolling my UserProfile model back into a custom User subclass... would save a lot of DB queries. :)

Yes. The joy of reasonable defaults and an opinionated way of working.

Some people loathe that but it frees me to think about the customer's actual problem rather than merely tidying my pencil case.

Oh, I get it now. Thanks!

Some reasons you might pick Django over Flask:

You want to be productive out of the gate - Django has the batteries included philosophy, so there's less time spent wiring together different libraries.

Fewer architectural decisions - Django is fairly opinionated about where to put things (less than Rails, but more than Flask). For some people who have problems with bikeshedding, this is a big win. Having all of the pieces tightly integrated means less time fiddling. As a sidenote this can really help when onboarding new developers. A complaint I've heard with Node/ReactJS apps is that they can be organized in any number of ways, and so knowledge doesn't carry over from one project to the next as well.

Class based views - Django has a really cool concept called class based views, where you can compose the "controller" functionality of your app with mixins. See ccbv.co.uk for a nice explanataion. Django is really really good at CRUD apps, and you are probably building something that does mostly CRUD or can be convinced that it is CRUD.

"More popular," and therefore more people use it and therefore more open source 3rd party packages to use and more people to get help from and more people to choose from when hiring. One metric - Stack Overflow has 154k questions on Django, and 18k questions on Flask.

"More mature" - this could be questionable, but Django is 12 years old vs Flask's 7 years, and Django has 25k Git commits vs Flask's 3k. This means more person-hours have gone into Django than Flask.

None of this is to say that Flask is not a capable framework. It looks pretty solid for what it offers. But the choice of framework is a decision that should be informed by the business requirements, unless it is a personal project and then use whatever you want. Hope this is helpful.

If you're interested in trying a hybrid approach, I find that Web2py offers the best of both worlds. It's batteries included in that it offers most of Django's features, but the author understands API aesthetics, much like Flask's author, and so it's a delight to use.

I started with Flask, tried Django, was disgusted by the gross API, and then I found web2py where I now sit happily :)

I love Flask for mini-apps and micro-services. I pretty much use it when I want to run a single python file with a web-facing component. It's also great when I need to build simple celery or task/cron-based apps. Like the other commenters have already pointed out, if you need a full-fledged website, Django.

The killer feature is the ecosystem. You have plug and play libs for every thing.

I too am curious. I had trouble getting started with Django but once I tired Flask everything seemed to make sense.

A definite downside of Django is learning curve. I'd argue Django is harder at first but easier in the long term.

Exactly; it takes time to learn the thing—it's huge compared to Flask. The documentation is killer though. I've been learning django for at least a few years now. I try not to rush, I know I'll figure it out eventually is basically my philosophy.

Django definitely has top tier documentation. I'd recommend first reading the official tutorial, then trying to make something with it and referring to the different sections as needed. For people wanting to go to the next level Two Scoops of Django is a fantastic book on best practices, and even more opinionated than Django, which I consider to be a great thing.