8 ms·

A good article, but I don't want the Flask web framework (http://flask.pocoo.org/ http://flask.pocoo.org/) to go unnoticed. I struggled along with Django for a

A good article, but I don't want the Flask web framework (http://flask.pocoo.org/ http://flask.pocoo.org/) to go unnoticed. I struggled along with Django for a number of months, and since I was just beginning web development I felt like I was fighting the large framework, even to build the simplest app. Upon discovering Flask I found it refreshingly simple, and when I moved on to more complicated applications I found it scaled beyond 'toy' apps. It really is worth a look for any Python developer.

tjr 14y ago
Anyone have experience with Flask vs. CherryPy? I started using CherryPy a few years ago and really liked it, but recently Flask [which looks conceptually similar to CherryPy] seems to be (amongst minimal Python web frameworks) the more hip and popular choice.
- pestaa 14y ago
  You can use both of them on the same project. The reason is that CherryPy is primarily a web application server, and Flask is primarily a web framework. (I'm not sure why you would want to do that, because Flask comes with Werkzeug, which is better integrated and I trust its author a bit more.) Also, I've never seen a better documentation than Flask's.
  - reinhardt 14y ago
    > (I'm not sure why you would want to do that, because Flask comes with Werkzeug) Well for one, Cherrypy-the-web-server is actually good enough for production. There is much to be said for the benefits of having the same deployment environment in development and production.
    - pestaa 14y ago
      If you imply Werkzeug is not production-ready, can you please elaborate why?
      - reinhardt 14y ago
        I don't imply it, it's explicitly spelled out (http://werkzeug.pocoo.org/docs/serving/ http://werkzeug.pocoo.org/docs/serving/): The development server is not intended to be used on production systems. It was designed especially for development purposes and performs poorly under high load. For deployment setups have a look at the Application Deployment pages.
teilo 14y ago
I've used both Flask and Django for apps that are both simple and complex. What I have discovered, is that if I use Flask for a complex app, I need to organize my code in clean components that end up looking like Django. Yes, I can do this more-or-less in a freeform manner with Flask, and even use the "one file for everything" method, but for a complex app, I wouldn't want to. It's too hard to manage. So, in the end, I end up mimicking the basic structure of a Django project: Models, Views, Forms, Utilities, etc. Yes, different ORM, different Form library, WSGI middleware instead of context processors, etc., but all-in-all, no less complex than had I used Django. It's really to the point that I find it hardly any faster to code in Flask for all but the most basic sites. I still use Flask for super simple projects that require no Admin interface, such as Personalized URL sites for ad campaigns. So it certainly has it's place.
- pestaa 14y ago
  MVC is a local maxima we found to build complex apps. Complex app will always require complex structure no matter the environment. I don't want to disagree on something I don't have much experience with, but at the same time, I'd like to hear more about how you build your projects. (In addition, considering there are two viable options for plug-and-play Flask admin interfaces, I don't know why you made it sound difficult.)
  - teilo 14y ago
    I'm not saying it is more difficult. I'm saying that it's not any less complex by the time you put everything you need together. In other words, it's a wash, so I just use Django instead. Fewer dependencies to install, fewer helper functions to write (because many of them already exist), and more components that are designed to work together. And then there are other things such as having all of your URLs specified on one place vs. as decorators with your controllers. But that's just my personal preference.
- lucian1900 14y ago
  I'd say getting SQLAlchemy instead of the terrible Django ORM is enough of an advantage. However, I have also found the tools around Django's ORM to be quite useful (admin, south).
LeonidasXIV 14y ago
At the time of writing, there was no Flask and Werkzeug wasn't really popular by then. An updated version would mention Flask of course.

tjr 14y ago

Anyone have experience with Flask vs. CherryPy? I started using CherryPy a few years ago and really liked it, but recently Flask [which looks conceptually similar to CherryPy] seems to be (amongst minimal Python web frameworks) the more hip and popular choice.

pestaa 14y ago
You can use both of them on the same project. The reason is that CherryPy is primarily a web application server, and Flask is primarily a web framework. (I'm not sure why you would want to do that, because Flask comes with Werkzeug, which is better integrated and I trust its author a bit more.) Also, I've never seen a better documentation than Flask's.
- reinhardt 14y ago
  > (I'm not sure why you would want to do that, because Flask comes with Werkzeug) Well for one, Cherrypy-the-web-server is actually good enough for production. There is much to be said for the benefits of having the same deployment environment in development and production.
  - pestaa 14y ago
    If you imply Werkzeug is not production-ready, can you please elaborate why?
    - reinhardt 14y ago
      I don't imply it, it's explicitly spelled out (http://werkzeug.pocoo.org/docs/serving/ http://werkzeug.pocoo.org/docs/serving/): The development server is not intended to be used on production systems. It was designed especially for development purposes and performs poorly under high load. For deployment setups have a look at the Application Deployment pages.

teilo 14y ago

I've used both Flask and Django for apps that are both simple and complex. What I have discovered, is that if I use Flask for a complex app, I need to organize my code in clean components that end up looking like Django. Yes, I can do this more-or-less in a freeform manner with Flask, and even use the "one file for everything" method, but for a complex app, I wouldn't want to. It's too hard to manage. So, in the end, I end up mimicking the basic structure of a Django project: Models, Views, Forms, Utilities, etc. Yes, different ORM, different Form library, WSGI middleware instead of context processors, etc., but all-in-all, no less complex than had I used Django. It's really to the point that I find it hardly any faster to code in Flask for all but the most basic sites. I still use Flask for super simple projects that require no Admin interface, such as Personalized URL sites for ad campaigns. So it certainly has it's place.

pestaa 14y ago
MVC is a local maxima we found to build complex apps. Complex app will always require complex structure no matter the environment. I don't want to disagree on something I don't have much experience with, but at the same time, I'd like to hear more about how you build your projects. (In addition, considering there are two viable options for plug-and-play Flask admin interfaces, I don't know why you made it sound difficult.)
- teilo 14y ago
  I'm not saying it is more difficult. I'm saying that it's not any less complex by the time you put everything you need together. In other words, it's a wash, so I just use Django instead. Fewer dependencies to install, fewer helper functions to write (because many of them already exist), and more components that are designed to work together. And then there are other things such as having all of your URLs specified on one place vs. as decorators with your controllers. But that's just my personal preference.
lucian1900 14y ago
I'd say getting SQLAlchemy instead of the terrible Django ORM is enough of an advantage. However, I have also found the tools around Django's ORM to be quite useful (admin, south).

LeonidasXIV 14y ago

At the time of writing, there was no Flask and Werkzeug wasn't really popular by then. An updated version would mention Flask of course.