
Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... - shabda
http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/
======
jgalvez
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-
devel...](http://tom.preston-werner.com/2010/08/23/readme-driven-
development.html)

[2] <http://jonasgalvez.com.br/Writings/Casual-Testing.html>

~~~
rguzman
_loosely coupled components are the way to go_

I disagree. Had you added "in some situations" I wouldn't.

The point of the frameworks, which are heavily coupled components with many
constraints, conventions and hidden parts of functionality is _rapid
prototyping_. That means that you can go from 0 to something quickly without
knowing all the details. For a large class of use-cases the ability to get
something out there fast is more important than the technical debt you may
incur by not knowing how everything is loaded. This is the case for a lot of
new products, startups and such.

On the flipside, if you have a very solid spec of what you're building (for
example, if you are re-writing an already-existing piece of software with a
browser-level test suite as spec so that it is easier to scale) then loosely
coupled components are likely the way to go. And yes, as soon as scale comes
into question loosely coupled components that you understand well are the way
to do it. This just isn't _always_ the case.

Secondly, it is not clear whether the frameworks get in your way that much. I
remember reading a blogpost about a shop replacing django bit by bit until
there was no django. That seems pretty cool. On the other hand, there is
disqus, which used django from the get-go, I think, and haven't swapped it
out, but just built a lot of tools around it. On the third hand, there is
probably a lot of sites that start with loosely coupled components and keep
refining. They are all valid approaches. At the time you are starting it is
usually unclear how to go about it.

In general I agree that people should try to understand how their tools work,
but there are only so many hours in a day, y'know?

~~~
jgalvez
You have a point. Let me elaborate my thoughts on Flask a bit further.

Personally, my experience is that for rapid prototyping, there's nothing
better than starting with the absolute minimum possible, and with a full-blown
monolithic framework, the absolute minimum is, more often than not, too much.

I prefer starting a project with a couple of files, like fabfile.py and
app.py, than starting a project with a bunch of directories and tons of
blueprinted configuration files. It's hard to explain why, I just feel it's a
lot easier for me to evolve an idea, from a small prototype to a finished
product, with this approach. I guess the cognitive signal to noise ratio is
just higher that way. I know many people share this feeling, otherwise Sinatra
and all these Python microframeworks wouldn't be getting so much attention.

I think a good framework is like a good government, consistent, helpful, but
with self-limiting interference. I think documentation is way more important
than features. I'll take a well written web development patterns guide over a
framework that does it all for me under the hood any day. The thing is that
Flask tries to be both. Flask's documentation is absolutely fantastic. It is
no surprise, of course, since it comes from the same guys who made the Sphinx
documentation builder.

I like conventions. I just don't think they ought to be mandatory. I see Flask
as a genome of web applications, with pre-defined solutions and information on
how to accomplish a series of things, but my application itself doesn't have
to be a grown organism from the beginning, it can start small, like an embryo,
and slowly grow in size. Flask gives you enough flexibility to employ
conventions but also do things differently, to invent your own way, when you
feel that you need to.

------
acgourley
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
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
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.

------
justin_vanw
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
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/>

------
qjz
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
I plan to do another set with a complexer app, and then do an actual
comparison.

------
intranation
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
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.

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

~~~
shabda
About 6 hours for reading on the various frameworks, about 6 hours to code.

------
mcs
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
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/>

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>],
which is built from the ground up specifically to use Eventlet.

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

~~~
mkramlich
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
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 :)

------
amirmc
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.

