I am so starving: Web app in python frameworks.

Massimo 7th Nov., 2010

Very nice! Would you add a web2py example too? I just made it:

Controller:

import urllib
from gluon.contrib.simplejson import loads

def index():
endpoint='http://graph.facebook.com/search?q="so%20starving&type=post'
def get_data(): return loads(urllib.urlopen(endpoint).read())['data']
data = cache.ram(endpoint,get_data,30*60)
return dict(data=data)

template:

{{extend 'layout.html'}}

{{ for post in data: }}

{{=post['message']}} : {{=post['from']['name']}}

{{ pass }}

(assuming it is ok using the default layout.html)
It is [running here](http://web2py.com/fmld) and the source code is here [as a zip](http://web2py.com/fmld/static/fmld.zip) or [as a w2p](http://web2py.com/fmld/static/web2py.app.fmld.w2p).

Waleed 7th Nov., 2010

Would you consider writing your thoughts about writing in each of the frameworks? Which was easiest to user and which was the most fun to work on?

foobar 7th Nov., 2010

@massimo lol! dude stop poking around doing one man publicity pitches here there and everywhere.

Seun Osewa 8th Nov., 2010

You left out CherryPy??? It's the best minimalist framework.

Julien 8th Nov., 2010

I was wondering why pylons was left out and I would appreciate a brief summary of your experience with all those framework.

Shabda Raaj 8th Nov., 2010

If you fork on github and send me a pull request, I will include Pylons and CherryPy.

Jonathan 9th Nov., 2010

No TurboGears 2 ? :(

rosetta stone 31st March, 2011

Our website offers the Cheap Rosetta Stone on sale,such as these very popular kinds: Rosetta Stone Spanish,Rosetta Stone German,Rosetta Stone Italian and so on,besides,there are many friendly customers who left useful Rosetta Stone Reviews,which maybe the good guide for you!
All the Rosetta Stone are 100% satisfaction guaranteed,and free shipping.We guarantee its quality,and all money will be refund if the goods are not satisfied.
welcome to make a purchase.

j 14th Jan., 2012

so guys, which is the best, I'm hesitating between Flask and Tornado for a quite simple project, I've used web2py and I like it

ugg-boots-sale.ucoz.com 17th Nov., 2012

A bad workman quarrels with his tools.Don't be so modest.How about a drink tonight? It's against the rules to handle the ball in soccer.Shut up!I don't know if I'll have the patience.I don't know if I'll have the patience.I know all about it.i have become a beast of burden.he didn't bat an eyelid.

Neriboy 1st Dec., 2012

Nov23 I saw your post in the MT forums, I see you got November to show up. Once you get the hang of MT, I'm sure you'll enjoy it even more. Good Luck.

TopCloudHosting 7th Nov., 2010

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: http://bit.ly/cnYk3x

baselogic 7th Nov., 2010

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: ... http://bit.ly/aX06Vp pt

baselogic 7th Nov., 2010

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x# ... http://bit.ly/crrI0B pt

franciscocosta 7th Nov., 2010

Web app in python frameworks http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

Purple_Design 7th Nov., 2010

I am so starving: #Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

wPythonnews 7th Nov., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/9Py8yn

morenosan 7th Nov., 2010

I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

softmodeling 7th Nov., 2010

RT@gsempe: The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x

StumblingRumble 7th Nov., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

aaloy 7th Nov., 2010

RT@morenosan: I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

newsyc50 7th Nov., 2010

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

_olivier_ 7th Nov., 2010

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

amicel 7th Nov., 2010

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

colbyolson 7th Nov., 2010

That would be really interesting to see the details required for each framework in comparison to each other.

TY 7th Nov., 2010

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/

Ixiaus 7th Nov., 2010

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.

natrius 7th Nov., 2010

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/

LiveTheDream 7th Nov., 2010

You should maximize the use of ready-to-use extensions once you know how things work, whether yours or the community's.

rguzman 7th Nov., 2010

loosely coupled components are the way to goI 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?

newgame 7th Nov., 2010

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.

jokull 7th Nov., 2010

+1 for Flask. It very much gets out of your way. Interestingly it still feels like you have it both ways (batteries included but loosely coupled) as the series of extensions are high quality thin wrappers for good libraries - namely Babel, Fungiform and SQLAlchemy. For me this was a great introduction to these aforementioned libs.

justin_vanw 7th Nov., 2010

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.

derwiki 7th Nov., 2010

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

ubernostrum 7th Nov., 2010

Funnily enough, most of these frameworks' caching tools will set the appropriate outgoing headers for you. Which I'm pretty sure you know. I'm pretty you also know that "just set the HTTP cache headers" covers only a tiny fraction of the actual problem.

bboomslang 7th Nov., 2010

I guess you meant "not fiscally viable to use multiple machines" because I am quite sure last time I looked a lot of the queue packages came free.

charlvn 8th Nov., 2010

I am so starving: Web app in python frameworks. http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

davidltaylor 8th Nov., 2010

RT@charlvn: I am so starving: Web app in python frameworks. http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

MiltonDz 8th Nov., 2010

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://goo.gl/UdWWB

suitter_bot 8th Nov., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/8CfWH

newsyc100 8th Nov., 2010

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

ActiveState 8th Nov., 2010

Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

benmurray 8th Nov., 2010

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

MatToufoutu 8th Nov., 2010

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

nekrox 8th Nov., 2010

@chglz tambien, voy a subir a github las cosas algo mas o menos así http://bit.ly/csaVbz

veverkap 8th Nov., 2010

RT@newsyc100: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

danenania 8th Nov., 2010

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

mkramlich 8th Nov., 2010

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!

mkramlich 8th Nov., 2010

web.py is similar in philosophy and verbosity, and probably older as well

jgalvez 8th Nov., 2010

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.

jgalvez 8th Nov., 2010

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

hackoder 8th Nov., 2010

I personally see django vs flask (or other microframework) as this:- Use a framework that has adequate components but they are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework. - Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code. I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well. That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc. Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django. [1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month. Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.

hackoder 8th Nov., 2010

I personally see django vs flask (or other microframework) as this:- Use a framework that has adequate components that are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework. - Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code. I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well. That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc. Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django. [1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month. Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.

Jeunito 8th Nov., 2010

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

yurevich 8th Nov., 2010

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

blackthorne 8th Nov., 2010

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

TopHackerNews 8th Nov., 2010

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/9UoTsc http://ff.im/-tlyVN

drahcir 8th Nov., 2010

that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.

ericmoritz 8th Nov., 2010

I apologize if I gave that impression. I intended to mean that it is my impression that frameworks encourage the use of talking to memcached directly instead of encouraging the use of HTTP caching. I believe that it would be better if web developers started with HTTP caching (and a caching proxy) and only relied on memcached directly when absolutely needed.

ericmoritz 8th Nov., 2010

I think you'll find that many of the authentication and personalization problems will go away if you put the client's state in their browser and don't keep track of it on the server. If you'd look at the type of sites we build, news sites, most of the content is common among all users. The personalization stuff can be either stored in the browser using localStorage, Dojo.storage or cookies and inserted using javascript. That'll cut out the need to personalize the page on the server. If the personalization is not done on the server, then the content of the page becomes common among all users. Slap a two second expiration on it and Varnish in front of it and tada, Django doesn't have to mess deal with it for a few hundred requests. Other things, such as personalized lists of stories can be fetched on-demand using AJAX (if it needs to be included on a HTTP cached page). If it's personalized, google will never see it so there's no real reason to not pull it in using AJAX. Since the personalized list of stories is now a separate resource from a common list of stories. We can use the vary header to cache that page based on the auth tokens. If you're targeting a platform that can't keep local state, like a dumb phone, then you'd want to create a state-full layer on top of your stateless site/web service. You'd piece together data while fetching it through the proxy layer. All the common data will be cached and fetched really fast and all the personal stuff will be be as slow as it would be if fetched via AJAX. Invalidation is a hard problem. Often, the solution is to keep the expiration times short enough so that stale content doesn't stick around. The same is often true with memcached. I don't find myself having to delete keys from memcached because the with the data I'm caching, eventually consistent is good enough.

grotgrot 8th Nov., 2010

Have a look at [this video](http://video.google.com/videoplay?docid=6297126166376226181) done a few years ago by a guy at NASA comparing various web frameworks including Java and Ruby ones. It is a nice presentation style and you may find some of the things he compares useful to look at too (restarts, errors, auth etc).

rlaksana 9th Nov., 2010

Writing a Web app in multiple python frameworks - Comparisons... - http://su.pr/1C5gI5

simonbowen 9th Nov., 2010

@marcfowler I wouldn't recommend Django, you'll start off with all their components, then rip them out later. Look here http://bit.ly/d2FLlc

justinvincent 10th Nov., 2010

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

ww2air 10th Nov., 2010

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

omargomez 10th Nov., 2010

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

typeoneerror 10th Nov., 2010

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

delicious50 10th Nov., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/cxrYxN

saperduper 13th Nov., 2010

? I am so starving: Web app in python frameworks. - The Agiliq Blog http://is.gd/gZXBD

alanplum 15th Nov., 2010

You fail at reading comprehension, both in the title and the linked article.

ubernostrum 29th Nov., 2010

I think what you want to do here is *look at how this stuff is actually implemented*. For example, Django's cache middleware and its caching decorator for individual views (which are actually the same code) set the outgoing `Expires` header (and `ETag` if you're using those, and `Last-Modified` when needed). This gets you best of both worlds: things which respect HTTP caching will respect those headers. And things which don't will still get responses served out of server-side cache. Which is necessary: if you're under the impression that we live in a happy world where every client respects HTTP caching, brother, I've got some bad news for you...

ericmoritz 29th Nov., 2010

I'll have to add that the test I'm doing is not a comparison of framework speed but the failure of the way we all do caching at the moment.

delicious_n_hot 9th Dec., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/fi6GEB #delicious #popular

deliciouspb 9th Dec., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/f0E6FX

hot_delicious 9th Dec., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3XzF

futuramiah 9th Dec., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3Ybb #delicious

joshva 9th Dec., 2010

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/i8CDs9

KarenKinnaman 9th Dec., 2010

via Del.icio.us : I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/aAYajF #social #networking

glyphobet 21st Jan., 2011

@krishnaroskin Flask. Or read http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

akhenakh 19th Feb., 2011

Comparing #python web framework http://bit.ly/hTY3M3

We are a small, intelligent App development studio. We love "Building Amazing Apps", solving problems and cultivating strong relationships with our clients.

By : Shabda Raaj

Copied from the Readme.

Microframeworks:

Full stack frameworks:

Related Posts

Comments

Reactions