[anthonyb]

It doesn't contain everything you need at all - that's why it's called a microframework.

If you want to use an ORM, or have database backed sessions, or user logins, you need to write all that yourself. For example: http://flask.pocoo.org/docs/patterns/sqlalchemy/

Depending on what you're doing, that might be a good thing - but I find writing things which are already included in Django pretty annoying.

[recuter]

Depending on the complexity of the project it might take you just as long to read how a monolithic framework decided to tie everything together (warts and all, because that will inevitably have historical cruft and technical debt).

The extensions were mentioned; User logins for example are just a "pip install Flask-Login" and "from flaskext.login import whatever" away. I had reason to roll my own, ~100 simple lines that were easily plugged.

There are pros and cons, neither is "better", the right tradeoff depends on what you're making.

[anthonyb]

Well, except that the login process for Django has a lot more people looking at it, and you know that the parts are going to work together pretty well.

For example, Flask-Login (https://github.com/maxcountryman/flask-login/blob/master/fla...) imports md5 and sha1 - not a very good sign. How do I make it use something sane? Well, there's Flask-Bcrypt, which provides bcrypt hashing... except that it makes no mention of Flask-Login or how to integrate it. Flask-Login also doesn't mention Flask-Bcrypt.

So... you're back to hacking on or digging into Flask-Login to figure out how it works and making it use Bcrypt or some other hashing algorithm.

Wait - I just realised that Flask-Login doesn't handle storing user data or models, or checking passwords, just logging them in. So what do I need for that? Is that Flask-Principal? And just WTH is an IdentityContext, anyway?

  An IdentityContext is the context of a certain identity
  against a certain Permission. It can be used as a 
  context manager, or a decorator.

You see why people use Django now? :) Sometimes you just want the standard user-logging-in-and-storing-in-the-database without having to write it yourself.

[wfn]

True that.

However, the Extensions library [-1] (which is not strictly speaking part of Flask) provides quite a lot of functionality - apart from your referred SQLAlchemy (which does the job well in our backend), there's a nice API generation factory [0] [1] and other neat stuff. For quite a lot of intents/purposes, flask extensions will do the job. But in the end of course it is a microframework. (From limited personal experience, a very neat general-purpose microframework nevertheless!)

[-1] http://flask.pocoo.org/extensions/ [0] [1] A particularly sexy example that simply uses models from SQLAlchemy (from the quickstart in [0]): manager.create_api(Person, methods=['GET', 'POST', 'DELETE']) manager.create_api(Computer, methods=['GET'])

where Computer and Person are DB models easily defined with the help of SQLalch.

(This is not to counter (there isn't anything to be countered, just providing links / luring people..)

[brass9]

Flask fan here.

Flask is not a "micro" microframework per se.

It provides a thin facade over werkzeug - which is anything but lightweight or micro.

[irahul]

* Flask fan here. Flask is not a "micro" microframework per se. It provides a thin facade over werkzeug - which is anything but lightweight or micro.*

Another Flask fan here. If Armin says Flask is micro, and other frameworks which aren't considered micro are far larger than Flask, what makes Flask not a micro framework?

[TazeTSchnitzel]

>It doesn't contain everything you need at all - that's why it's called a microframework.

I said everything you need to make web apps in Python, and I stand by that. Maybe it doesn't have an ORM or user account management, but for my purposes, it's great for small apps.