8 ms·

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ...

114 points by shabda 16y ago

pama 16y ago
What was the development time of the webapp in each of the frameworks?
- shabda 16y ago
  About 6 hours for reading on the various frameworks, about 6 hours to code.
acgourley 16y ago
Not to diminish the contribution from shabda - but what would really interest me is hearing about these frameworks from the perspective of someone who has launched and maintained a complex system, not a toy app.
- shabda 16y ago
  Probably over the next weekends, Ill do a basic blog in these frameworks. Not complex, but should give me a chance to test the ORM, Session, Cookies etc.
  - rguzman 16y ago
    I think you'll find that all of them are very similar in terms of ORM, Session, Cookies, etc -- they are, more or less, the same toolbox. However, the devil is in the details. Once you start managing something sufficiently complex you start to see what details constrain you in bad ways and such. I'd guess that you don't get to that point until way after you launch.
  - colbyolson 16y ago
    That would be really interesting to see the details required for each framework in comparison to each other.
- Ixiaus 16y ago
  I've built my startup entirely in Python + Pylons (1.0). Pylons is wonderful, I really like it a lot and I'm excited about its future too (move to Pyramid which is basically repoze.bfg). The application I'm running is large, complex, and has quite a few moving parts. I run it under mod_wsgi in Apache and use the Paster server when developing on my local machine. I particularly love the unit testing harness for Nose that Pylons provides.
jgalvez 16y ago
FWIW, I've been using Flask. It seems to be the one having the most traction and support these days. But I think frameworks are not that important. I use Flask mostly for its HTTP request handling functionality. But everything else is my own (e.g., the overall setup, configuration etc). I think what's most important is understanding that loosely coupled components are the way to go. Know how your scripting language loads and manages modules and try to get to a simple convention on how to organize your code. Minimize the use of ready-to-use extensions and just try to effing know. how. things. work. Glue code together yourself. Document religiously how you did it[1]. It'll save you a world of trouble. The one tool that has been central to my web development work in Python is pretty much framework-agnostic: Fabric. My projects start with a single fabfile.py and and lib/ directory. I do most of the prototyping in the fabfile.py, which serves as a sort of adhoc testing sandbox[2]. And then I start adding request handlers and writing markup/css. With this approach, whether you're using Flask, webpy or Juno (my faves) is irrelevant. But sticking with Flask might give you a more enthusiastic and active community nowadays. [1] http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel... [2] http://jonasgalvez.com.br/Writings/Casual-Testing.html http://jonasgalvez.com.br/Writings/Casual-Testing.html
- godDLL 16y ago
  Flask looks delicious. On the other hand, for this specific app -- bottle, itty and juno all look very similar to the app made with flask. For whatever reason I find this very Pythonic.
  - mkramlich 16y ago
    web.py is similar in philosophy and verbosity, and probably older as well
- derwiki 16y ago
  (Flask for its HTTP request handling functionality)++ This is the _main_ reason I chose Flask to work on a new project. After using our in-house proprietary framework for a year and a half, I wanted to see if I could do any better. But the HTTP request part sounded boring. Enter Flask: it let's me grow the framework into exactly what I want it to be.
amirmc 16y ago
Thanks for the post but I find the title of the link a bit confusing "Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ..." I'm not sure what you're comparing.
danenania 16y ago
web2py deserves a place on the list. I've found it to be more productive than django.
- randallsquared 16y ago
  It's in the github repo.
  - drahcir 16y ago
    that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.
- mkramlich 16y ago
  that project's choice of name, web2py, drives me apeshit. i much preferred it when it was called gluon. web2py both (a) sounds way way too much like web.py, which predated it, and (b) it sounds like it's a successor to it -- which it is not, and (c) sounds like it's a conversion tool of some kind (following the whole "foo2bar" pattern in program naming). Whereas 'gluon': some small thing which binds the universe together. And it has personality!
  - danenania 16y ago
    Yeah, I also prefer gluon. It had to be changed due to a copyright issue from what I gather. That said, I could give a hoot what a framework is named if I get work done quickly with it :)
mcs 16y ago
I realize that scalability probably wasn't a concern when you made these demos.. but it doesn't look like any of these can handle many concurrent requests (incoming, or outgoing to facebook). Are any of these frameworks even compatible with the event driven mechanisms like twisted, tornado, etc? I'm having to pick up Python since a lot of the webapp infrastructure at the startup I joined is Python/Django and I haven't really liked it so far, especially since everything we do would benefit from being done in an event loop (tons of IO to background services that make web requests block)
- ericflo 16y ago
  These examples can be made to run in a completely evented style with no code changes using Eventlet. I use this for pretty much all of my projects these days: http://eventlet.net/ http://eventlet.net/ One of the most popular WSGI servers these days, gunicorn, has a simple configuration option that lets you switch on Eventlet transparently. Or you can use something like Spawning [http://pypi.python.org/pypi/Spawning http://pypi.python.org/pypi/Spawning], which is built from the ground up specifically to use Eventlet.
- shabda 16y ago
  Afaik, All of these are WSGI. So You would be them behind a WSGI container, so incoming concurrent requset wont be a problem. Outgoing requests should be fairly rare with Data from FB cached.
- TY 16y ago
  Thanks to WSGI you can. For example, here's a handy page in Flask's (outstanding I might note) documentation on how you can run it on Tornado, Gevent and Gunicorn: http://flask.pocoo.org/docs/deploying/others/ http://flask.pocoo.org/docs/deploying/others/
qjz 16y ago
I hope there's going to be a followup discussing the strengths and pitfalls of each, along with the the original specifications of the app, so we can see where a framework imposed limitations or even provided a better approach to implementing a feature.
- shabda 16y ago
  I plan to do another set with a complexer app, and then do an actual comparison.
intranation 16y ago
This is hardly an apples to apples comparison. Pyramid (ex-Pylons) and Django are "full-stack" frameworks with everything incuding the kitchen sink. App Engine only runs on App Engine, so probably isn't that relevant anyway. The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so. It's possible to use both in a project, for example we at Smarkets use Django for the main site (as we have tonnes of URLs and complexity), and use Flask for a RESTful API to our search engine. I wouldn't dream of swapping or comparing them: they both do their own job very well.
- newgame 16y ago
  Just a remark. The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so. I don't think the attribute micro relates to the size of the projects you can create with these frameworks but rather the way they are written: Keep the core small and rely on external libraries for specific functionality.
justin_vanw 16y ago
What is the point of making toy apps? Make a complex app that evolves over a period of 2 or so years, and then tell me how it went. Much of the time the framework where it is easiest to make a toy app is the one that has lots of hidden, implicit assumptions that come back to fuck you when you need the flexibility to do something that violates those assumptions. Having dealt with python frameworks for several years and developed several complex apps, I'm not willing to use anything other than werkzeug. It's lightyears ahead of than else out there (flask is werkzeug wrapped in shit you don't need with the intention of making it more popular). Pylons is also very nice, although it tries to do too much for you, and has too much magic for my taste. The context-local request and response objects in pylons are a double edged sword that I find cuts the wrong way too often.
natrius 16y ago
Neat, but you should check out PEP 8 at some point. An empty line between a decorator and the decorated function (flask) is confusing, and whitespace in keyword arguments just looks off. http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/

114 points by shabda 16y ago

pama 16y ago

What was the development time of the webapp in each of the frameworks?

shabda 16y ago
About 6 hours for reading on the various frameworks, about 6 hours to code.

acgourley 16y ago

Not to diminish the contribution from shabda - but what would really interest me is hearing about these frameworks from the perspective of someone who has launched and maintained a complex system, not a toy app.

shabda 16y ago
Probably over the next weekends, Ill do a basic blog in these frameworks. Not complex, but should give me a chance to test the ORM, Session, Cookies etc.
- rguzman 16y ago
  I think you'll find that all of them are very similar in terms of ORM, Session, Cookies, etc -- they are, more or less, the same toolbox. However, the devil is in the details. Once you start managing something sufficiently complex you start to see what details constrain you in bad ways and such. I'd guess that you don't get to that point until way after you launch.
- colbyolson 16y ago
  That would be really interesting to see the details required for each framework in comparison to each other.
Ixiaus 16y ago
I've built my startup entirely in Python + Pylons (1.0). Pylons is wonderful, I really like it a lot and I'm excited about its future too (move to Pyramid which is basically repoze.bfg). The application I'm running is large, complex, and has quite a few moving parts. I run it under mod_wsgi in Apache and use the Paster server when developing on my local machine. I particularly love the unit testing harness for Nose that Pylons provides.

jgalvez 16y ago

FWIW, I've been using Flask. It seems to be the one having the most traction and support these days. But I think frameworks are not that important. I use Flask mostly for its HTTP request handling functionality. But everything else is my own (e.g., the overall setup, configuration etc). I think what's most important is understanding that loosely coupled components are the way to go. Know how your scripting language loads and manages modules and try to get to a simple convention on how to organize your code. Minimize the use of ready-to-use extensions and just try to effing know. how. things. work. Glue code together yourself. Document religiously how you did it[1]. It'll save you a world of trouble. The one tool that has been central to my web development work in Python is pretty much framework-agnostic: Fabric. My projects start with a single fabfile.py and and lib/ directory. I do most of the prototyping in the fabfile.py, which serves as a sort of adhoc testing sandbox[2]. And then I start adding request handlers and writing markup/css. With this approach, whether you're using Flask, webpy or Juno (my faves) is irrelevant. But sticking with Flask might give you a more enthusiastic and active community nowadays. [1] http://tom.preston-werner.com/2010/08/23/readme-driven-development.html http://tom.preston-werner.com/2010/08/23/readme-driven-devel... [2] http://jonasgalvez.com.br/Writings/Casual-Testing.html http://jonasgalvez.com.br/Writings/Casual-Testing.html

godDLL 16y ago
Flask looks delicious. On the other hand, for this specific app -- bottle, itty and juno all look very similar to the app made with flask. For whatever reason I find this very Pythonic.
- mkramlich 16y ago
  web.py is similar in philosophy and verbosity, and probably older as well
derwiki 16y ago
(Flask for its HTTP request handling functionality)++ This is the _main_ reason I chose Flask to work on a new project. After using our in-house proprietary framework for a year and a half, I wanted to see if I could do any better. But the HTTP request part sounded boring. Enter Flask: it let's me grow the framework into exactly what I want it to be.

amirmc 16y ago

Thanks for the post but I find the title of the link a bit confusing "Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ..." I'm not sure what you're comparing.

danenania 16y ago

web2py deserves a place on the list. I've found it to be more productive than django.

randallsquared 16y ago
It's in the github repo.
- drahcir 16y ago
  that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.
mkramlich 16y ago
that project's choice of name, web2py, drives me apeshit. i much preferred it when it was called gluon. web2py both (a) sounds way way too much like web.py, which predated it, and (b) it sounds like it's a successor to it -- which it is not, and (c) sounds like it's a conversion tool of some kind (following the whole "foo2bar" pattern in program naming). Whereas 'gluon': some small thing which binds the universe together. And it has personality!
- danenania 16y ago
  Yeah, I also prefer gluon. It had to be changed due to a copyright issue from what I gather. That said, I could give a hoot what a framework is named if I get work done quickly with it :)

mcs 16y ago

I realize that scalability probably wasn't a concern when you made these demos.. but it doesn't look like any of these can handle many concurrent requests (incoming, or outgoing to facebook). Are any of these frameworks even compatible with the event driven mechanisms like twisted, tornado, etc? I'm having to pick up Python since a lot of the webapp infrastructure at the startup I joined is Python/Django and I haven't really liked it so far, especially since everything we do would benefit from being done in an event loop (tons of IO to background services that make web requests block)

ericflo 16y ago
These examples can be made to run in a completely evented style with no code changes using Eventlet. I use this for pretty much all of my projects these days: http://eventlet.net/ http://eventlet.net/ One of the most popular WSGI servers these days, gunicorn, has a simple configuration option that lets you switch on Eventlet transparently. Or you can use something like Spawning [http://pypi.python.org/pypi/Spawning http://pypi.python.org/pypi/Spawning], which is built from the ground up specifically to use Eventlet.
shabda 16y ago
Afaik, All of these are WSGI. So You would be them behind a WSGI container, so incoming concurrent requset wont be a problem. Outgoing requests should be fairly rare with Data from FB cached.
TY 16y ago
Thanks to WSGI you can. For example, here's a handy page in Flask's (outstanding I might note) documentation on how you can run it on Tornado, Gevent and Gunicorn: http://flask.pocoo.org/docs/deploying/others/ http://flask.pocoo.org/docs/deploying/others/

qjz 16y ago

I hope there's going to be a followup discussing the strengths and pitfalls of each, along with the the original specifications of the app, so we can see where a framework imposed limitations or even provided a better approach to implementing a feature.

shabda 16y ago
I plan to do another set with a complexer app, and then do an actual comparison.

intranation 16y ago

This is hardly an apples to apples comparison. Pyramid (ex-Pylons) and Django are "full-stack" frameworks with everything incuding the kitchen sink. App Engine only runs on App Engine, so probably isn't that relevant anyway. The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so. It's possible to use both in a project, for example we at Smarkets use Django for the main site (as we have tonnes of URLs and complexity), and use Flask for a RESTful API to our search engine. I wouldn't dream of swapping or comparing them: they both do their own job very well.

newgame 16y ago
Just a remark. The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so. I don't think the attribute micro relates to the size of the projects you can create with these frameworks but rather the way they are written: Keep the core small and rely on external libraries for specific functionality.

justin_vanw 16y ago

What is the point of making toy apps? Make a complex app that evolves over a period of 2 or so years, and then tell me how it went. Much of the time the framework where it is easiest to make a toy app is the one that has lots of hidden, implicit assumptions that come back to fuck you when you need the flexibility to do something that violates those assumptions. Having dealt with python frameworks for several years and developed several complex apps, I'm not willing to use anything other than werkzeug. It's lightyears ahead of than else out there (flask is werkzeug wrapped in shit you don't need with the intention of making it more popular). Pylons is also very nice, although it tries to do too much for you, and has too much magic for my taste. The context-local request and response objects in pylons are a double edged sword that I find cuts the wrong way too often.

natrius 16y ago

Neat, but you should check out PEP 8 at some point. An empty line between a decorator and the decorated function (flask) is confusing, and whitespace in keyword arguments just looks off. http://www.python.org/dev/peps/pep-0008/ http://www.python.org/dev/peps/pep-0008/