[chpmrc]

Honestly, I don't see the point of using Flask anymore. You can set up a Django project and just use a single module with a bunch of view functions, built-in testing and sensible defaults. Done. Not choosing that approach just because it takes a few more MBs on disk or needs a few more KBs of memory is shortsighted, IMO. You can't always predict what a project will end up needing.

I'm legitimately asking: why would you use Flask instead of Django, even if you don't (but might) need the ORM, admin etc.? Thanks!

[dagw]

why would you use Flask instead of Django

If you don't really know Django, the learning curve on Flask is a lot shallower. So if you don't need ORMs, models, admin etc. but you just want make those python scripts you wrote callable via a web browser then you'll get version 0.1 out the door a lot sooner with Flask.

Also a lot of Django kind of assumes the ORM as your data store. So if you need to use a primary data store that cannot be accessed via the ORM you lose a lot of what Django has to offer.

That being said, I agree that many 'simple' Flask projects have a tenancy to grow until you have implemented most of Django in Flask anyway.

[sonthonax]

Because Django is pretty badly designed, and it can get in the way when you need to do some more complex stuff. It get's the job done for 95% of cases, but that extra 5% can devolve into some pretty nasty stuff.

Typically the inflection for when Django becomes a nightmare is when you want to start splitting the application up. This is made really hard because Django depends on a whole load of globals (settings, urls, context preprocessors, the actual WSGI handler). With Flask you can have two separately configured applications running in the same process, routed with a bit of WSGI middleware.

This comes in handy when you need to do a 'soft' rewrite and have code running side by side. This also just makes things easier to test, because you can build a new application object for each test with it's own settings. You can't do that in Django with out a great deal of consternation; try creating two tests with different middleware stacks in Django, patching settings won't work because the application has already loaded, and there's no way to reload it between tests.

Also, for the same reason (as someone else said) it makes it tricky to use in non-web contexts. Like Celery.

Django's can't handle more complex database queries. If you've ever seriously used SQLAlchemy, you'll know what you're missing.

The ORM is also lacking a unit of work model, which can kill performance. The only way to create multiple objects in a single database round trip in Django is with `bulk_create`. But you can't create something like a group and then a user in a single database round trip. Sure you can create them in a single transaction, but that's not quite the same, because each roundtrip takes an extra millisecond. It's an easily avoided inefficiency that SQLAlchemy solves.

The template language is limited compared to Jinja2. While this is by design, it doesn't support streaming the response back. This is really annoying if you're generating massive templates. It would have also been really simple to do.

I could go on really.

[chpmrc]

You can use whatever ORM or templating library you want. But at least if one day you realize you need something that Django offers out of the box it's there for you to use.

And if not it's not like it has any perceivable effect on performance.

[philote]

> I'm legitimately asking: why would you use Flask instead of Django, even if you don't (but might) need the ORM, admin etc.?

If for some reason you wanted to use a noSQL database, Django's ORM and everything connected to it (like admin) won't work.

[chpmrc]

There are connectors for noSQL databases as well. Or it's surely easier to implement one than to reimplement everything else around the ORM.