4 ms·

Funny that I wrote that Flask is for advanced usage and you wrote that Flask is for simple usage. If the project is really simple - no database, no declarative

by aartur 13y ago

Funny that I wrote that Flask is for advanced usage and you wrote that Flask is for simple usage. If the project is really simple - no database, no declarative forms etc. - then Flask will be better. But if you go to "medium complexity" Django gives you ready components which you need to integrate in Flask (SQLAlchemy, WTForms etc.). You also need to invent your own project structure, and Django already has a hardcoded one. When the project complexity is "high" then Django starts to be too limited/"hardcoded" and flexibility/minimalism of Flask starts to shine.

dangoldin 13y ago
Haha yea you're right! Funny how my bias trickled through. I haven't done too much Flask customization and only use it for the one off simple project that just need a web interface. Django is definitely more in the range of "we want you to write" this way but I've found it to be at least a bit more customizable than RoR. Flask is on the other extreme which lets you do whatever you want.. but you're the one who has to do it.
numlocked 13y ago
I actually disagree. Flask does not necessarily shine with projects of high complexity. The framework designers themselves say as much: "However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application."[1] Flask is excellent when you just don't need a bunch of the stuff in Django, and don't need the batteries to be included. It's not so much that Flask is suitable to high-complexity apps, but more that it's suited to highly custom web apps. Building a music sharing app based on jQuery mobile and backed by Mongo? You're better off with Flask. But at scale you're going to end up doing something custom. Django is highly suitable if you need to manage users, have a variety of entities that lend themselves to the admin dashboard (more broadly, that the admin/public app metaphor even makes sense in the first place), and find a plug-and-play package system compelling. They are both great frameworks, but "complexity" (advanced/simple) is the wrong axis along which to evaluate them. [1]http://flask.pocoo.org/docs/design/ http://flask.pocoo.org/docs/design/
- dvanduzer 13y ago
  The "large applications or asynchronous servers" bit might be better understood in comparison to the monolithic versus micro kernel debate. Flask is well suited for building complex applications that can be decomposed into simple moving parts with a clear separation of concerns. (My personal bias is that all complex applications can and should be developed this way.) The documented limitation you reference is based on the WSGI server being used. "If your server uses some kind of concurrency that is not based on threads or greenlets, Flask will no longer be able to support these global proxies."[0] As nginx+gunicorn is becoming more popular, this isn't really an issue at all. [0]http://flask.pocoo.org/docs/becomingbig/#scale-like-a-pro http://flask.pocoo.org/docs/becomingbig/#scale-like-a-pro
- espeed 13y ago
  "However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application." Armin has said before that he needs to update/clarify that statement -- as dvanduzer said, it's not really relevant anymore.

by aartur 13y ago

dangoldin 13y ago

Haha yea you're right! Funny how my bias trickled through. I haven't done too much Flask customization and only use it for the one off simple project that just need a web interface. Django is definitely more in the range of "we want you to write" this way but I've found it to be at least a bit more customizable than RoR. Flask is on the other extreme which lets you do whatever you want.. but you're the one who has to do it.

numlocked 13y ago

I actually disagree. Flask does not necessarily shine with projects of high complexity. The framework designers themselves say as much: "However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application."[1] Flask is excellent when you just don't need a bunch of the stuff in Django, and don't need the batteries to be included. It's not so much that Flask is suitable to high-complexity apps, but more that it's suited to highly custom web apps. Building a music sharing app based on jQuery mobile and backed by Mongo? You're better off with Flask. But at scale you're going to end up doing something custom. Django is highly suitable if you need to manage users, have a variety of entities that lend themselves to the admin dashboard (more broadly, that the admin/public app metaphor even makes sense in the first place), and find a plug-and-play package system compelling. They are both great frameworks, but "complexity" (advanced/simple) is the wrong axis along which to evaluate them. [1]http://flask.pocoo.org/docs/design/ http://flask.pocoo.org/docs/design/

dvanduzer 13y ago
The "large applications or asynchronous servers" bit might be better understood in comparison to the monolithic versus micro kernel debate. Flask is well suited for building complex applications that can be decomposed into simple moving parts with a clear separation of concerns. (My personal bias is that all complex applications can and should be developed this way.) The documented limitation you reference is based on the WSGI server being used. "If your server uses some kind of concurrency that is not based on threads or greenlets, Flask will no longer be able to support these global proxies."[0] As nginx+gunicorn is becoming more popular, this isn't really an issue at all. [0]http://flask.pocoo.org/docs/becomingbig/#scale-like-a-pro http://flask.pocoo.org/docs/becomingbig/#scale-like-a-pro
espeed 13y ago
"However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application." Armin has said before that he needs to update/clarify that statement -- as dvanduzer said, it's not really relevant anymore.