7 ms·
Python web micro-framework battle
- 3KWA 15y agoThe video is also available at http://www.youtube.com/PyconAU#p/u/7/AYjPIMe0BhA http://www.youtube.com/PyconAU#p/u/7/AYjPIMe0BhA Interesting if somewhat very biased.
- wyclif 15y agotl;dr: Bottle wins.
- mhd 15y agoI think the scoring part (being very particular to the tester and not weighted at all) is the least interesting part of the presentation, the code and the comments for each framework are actually quite interesting. I just wish that Twisted / Tornade would've been in the fray.
- llambda 15y agoLine count is a silly way to score when all are around the same anyway (fewer than 100 lines). And the framework line count is another metric that shouldn't matter. That said, really the only valid point here against Flask is Python 3 support. Other than that Bottle and Flask are pretty much on par with each other.
- MostAwesomeDude 15y agoFlask has the advantages of fast templates, strong WSGI features, serious unit testability at the app and library level, complete documentation...
- llambda 15y agoDon't get me wrong, I love Flask. It's become my go-to web framework for Python. In my opinion it wins. But, that's just my opinion. :)
- zzzeek 15y agobut didn't you read the presentation ? templates are out man. Write your HTML as string concatenations "<html>" + helloworld + "</html>" right inside your __init__.py or YOU'RE NOT COOL.
- the_mitsuhiko 15y ago> Python 3 support Will come eventually. Right now the topic comes rarely up and it requires a ton of work on the Werkzeug side to make it work in a way that is user friendly. That being said, Flask and Jinja2 are not the problem here. The former easily works on Python 3 and the latter already does (just that we don't have any users on Python 3 yet).
- anthonyb 15y agoThe point behind the line count is that simpler code on the framework side counts, particularly when the documentation is sketchy or unclear. Less code for the same functionality means that you have less reading to do when learning the framework's intricacies.
- puredemo 15y agoPesto wins if you count the extra features at the end.
- nnythm 15y agoDiscounting pyramid as a microframework doesn't seem valid, given that it can be scaled up or down arbitrarily. https://docs.pylonsproject.org/projects/pyramid/1.2/ https://docs.pylonsproject.org/projects/pyramid/1.2/ has an extremely concise pyramid web app above the fold.
- the_mitsuhiko 15y agoIndeed. The whole concept of when a framework starts or stops being micro is quite arbitrary.
- anthonyb 15y agoCompare it with Bottle's version though and it doesn't look quite so concise any more: http://bottlepy.org/docs/dev/ http://bottlepy.org/docs/dev/
- mcdonc 15y agoSeems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designdefense.html#microframeworks-have-smaller-hello-world-programs https://docs.pylonsproject.org/projects/pyramid/1.2/designde...
- anthonyb 15y agoSeems pretty defensive to me. How does, say, separating out the route and the view declarations help your application? Code like this: config = Configurator() config.add_route('hello', '/hello/{name}') config.add_view(hello_world, route_name='hello') is really just boilerplate, which is better done as a decorator. Count how many times the word 'hello' appears in that snippet above. And this is just for a hello world program. Once you start on a real app, that's only going to multiply.
- mcdonc 15y agoIn a more traditional Pyramid app it would be done more like: from pyramid.view import view_config from pyramid.response import Response from paste.httpserver import serve @view_config(route_name='hello') def hello_world(request): return Response('Hello %(person)s' % request.matchdict) if __name__ == '__main__': config = Configurator() config.add_route('hello', '/hello/{person}') config.scan() serve(config.make_wsgi_app()) The config.scan() bit causes the @view_config decorators to be picked up. So we do have some decorators, although they don't populate an external registry (by design). The rationale for putting the route ordering in imperative code instead of using decorator declaration order is in the document I linked. I'm not particularly interested in crippling Pyramid for larger apps to race to the bottom of the LOC count. It's succinct enough and works for truly large apps too.
- LeafStorm 15y agoI don't think counting Python 3 support is really important for Web frameworks. All of the major server distros are still on Python 2.x anyway (last I checked, Arch is the only one where "pacman -S python" will get you Python 3 instead of 2), and the question of WSGI is still up in the air if you want to handle encoding properly instead of just fudge it.
- shabda 15y agoI did something similar a while back, in case any-one's still interested .. https://github.com/agiliq/so-starving https://github.com/agiliq/so-starving
- mattdeboard 15y agoWhere does one draw the distinction between micro- and megaframeworks? Or, for that reference, just a "framework"?
- d0m 15y agoThings a company will ask you to know is a megaframeworks. Else, it's a micro or simply framework. Obviously, I'm not serious here; but there's some truth in it. I.e. You'll see some companies ask for django or rails developers; not for flask python hacker right ;-)
- defnull 15y agoYour point is interesting, but I would look at it from a different angle: If you need a highly paid specialist with many years of experience to fully master a framework, call it mega-framework. If it fits your brain and can be learned over the weekend, its a micro framework. Everything in between is just a framework :)
- the_mitsuhiko 15y ago> Where does one draw the distinction between micro- and megaframeworks? Or, for that reference, just a "framework"? Here is how we (Flask developers) define microframework: http://flask.pocoo.org/docs/foreword/#what-does-micro-mean http://flask.pocoo.org/docs/foreword/#what-does-micro-mean
- DasIch 15y agoThe difference between a library and a framework is simply that you call the library whereas the framework calls you. The framework provides a frame into which you put your code as opposed to a library which you use as part of your code. Generally I would consider any framework which requires (almost) no setup requirements to be a microframework. This is opposed to frameworks which require a basic configuration, directory layout or certain files to be present. However there are a lot of other people with other definitions regarding this, the distinction is not at all very clear for example there are people that consider being written in a single file to be a distinguishing feature of microframeworks.
- binarycrusader 15y agoThe author's examples for cherrypy were way more complicated than they needed to be, and they didn't take performance into account. I also find some of the conclusions about its documentation and wsgi questionable. The author also drops some frameworks immediately due to maturity, but then fails to rank the remainder based on that. What about ipv6 and proper Unicode support? What about http/wsgi compliance? And of course, at the end they show all the extras the frameworks have but don't take those into account.
- the_mitsuhiko 15y agoI have no idea how the LOC numbers of Flask come together though. Flask itself is 1.4KLOC, Jinja2 is 6.5KLOC and Werkzeug is 10KLOC (all measured without tests). Even if you add them up you don't end up with 32KLOC.
- defnull 15y agoThe author probably did something like this: sudo pip install -u flask cd /usr/local/lib/python2.6/dist-packages find flask/ werkzeug/ jinja2/ -name '*.py' | xargs wc ... 34936 127298 1658380 total Werkzeug alone has 18KLOC and does not ship with tests.
- the_mitsuhiko 15y agoThose are not lines of code. That includes docstrings which all of Pocoo code is full of. If you want to measure lines of code you at least have to skip comments, docstrings and empty lines. And for that there is sloccount. This also includes the testsuites btw. With this little script (http://paste.pocoo.org/show/465885/ http://paste.pocoo.org/show/465885/) I get the following results: Flask 1467 LOC Jinja2 6560 LOC Werkzeug 9923 LOC Bottle 1910 LOC (FWIW)
- defnull 15y agoThere are better ways to count LOC, I agree. But the idea is the same: Bottle does what it does with 1/10 of the code that runs flask.
- the_mitsuhiko 15y ago> Bottle does what it does with 1/10 of the code that runs flask. Not all of the code that is in Jinja2 or Werkzeug is used by the average Flask application. Also Flask does a lot more than Bottle, even for the same things. The routing system behind Werkzeug itself already comes close to 1KLOC (and for good reasons). Which is why I think that any comparison between Bottle and Flask is pretty pointless, it's not really a fair fight for either. For Flask it was never a goal to have less code than another framework, in fact, from our perspective that's quite a pointless goal.
- vessenes 15y agoTo count out sessions and templating means truly "micro." I can't think of many useful web applications that do not require these to some extent. With those criteria, I'm sort of switching between Flask and Tornado right now. Speed is a major consideration with any python framework, too. You've got serious threading concerns. Even with Tornado, advertised as non-blocking, the default solution is nginx running against a whole bunch of tornado threads. ...
- socratic 15y agoI used web.py for a few years before switching over to mostly coding in Rails for the last few months. Is this for real? Do people find the difference between the style of these micro-frameworks substantial? Maybe I've been out of Python-land for too long, but 70% of these look almost identical (raising exceptions for redirects, a combination of lists and naming conventions or decorators for routes/methods, etc.) and the other 30% look awful. Furthermore, when all of the frameworks are basically the same, isn't a much more important question what scenario they were designed for, or what extra features they have, or performance, or how big a community they have? (Even where the author seems to have reasonable criteria, like WSGI, he doesn't seem able to look up that web.py is WSGI-based.) And seriously, does anyone care about Python 3 and/or PyPy support in 2011? Another way of putting this: do the criteria that the author lists match anyone's criteria who is currently writing Python web applications in the real world?
- kenneth_reitz 15y agoThis seems like an illogical conclusion. I didn't see API Design mentioned once in any of these slides. Aside from Python3 Support (which is a bit irrelevant at this point), what does Bottle actually offer that Flask does not? Nothing, that I can see. Flask has a thriving community, first-class extensions, extremely high quality documentation, and an elegant API. It even lets you dip down into the lower-level werkzeug when you want. Is Bottle being chosen because of LOC? Again, completely irrelevant.
- bonkabonka 15y agoBottle's API easy to understand and has sane defaults. It also doesn't require any boiler-plate code and isn't saddled with any dependency baggage. I found it trivial to wire in the Rocket web server as a replacement for WSGIref which had the added advantage I could wrap the startup in a small hunk of code I found over on the ActiveState forum to turn my app into a Windows service. Which, after half a day of beating on Flask, I wasn't able to figure out. shrug For me, it's all about fitness for purpose. In the end, the prototype consisted of four files (Bottle, Rocket, the Service wrapper and my code) with no other dependencies. Made it a lot easier for the overworked Windows admins to deploy. Flask was completely unsuitable for that.
- kenneth_reitz 15y agoFear of packages is a terrible thing. But, I see what you're saying. FWIW, there's a Flask-kitchensink project that lets you run it out of a single file, if you're so inclined.
- bonkabonka 15y agoThanks for the pointer to that project. Hopefully I won't have to do another of these off-the-cuff throwaways again (which means I won't have to leave the comfort-zone of virtualenv on Linux), but if I do, I now know where to find the kitchen sink. =)
- mcdonc 15y agoComments with critical, dogmatic hyperboles in them like this drive me nuts in general. Here are the hyperboles in this comment with the translations to normal English. - "saddled with any dependency baggage" == "has no dependencies" - "beating on Flask" == "using Flask" - "shrug" == "i didn't spend a lot of time on this" - "Flask was completely unsuitable for that" == "I was unwilling to ask for help from the people who use Flask" Additionally, Flask is also "easy to understand" and has "sane defaults", and it doesn't "require any boilerplate code" either. The context of the comment makes it seem like it's subpar on these things. I'm all for people pointing out fitness of purpose for various frameworks, but this comment might have been better phrased as "I use Windows. I happened to find a recipe that let me run Bottle as a Windows service. That made it easier for me to use Bottle. Also, I like being able to deploy without the use of packaging tools."
- rushabh 15y agoI also like the way bottle handles static files and apps compared to flask. I lost flask when it went into blueprints. Bottle seems more intuitive, though there is not much difference.
- DasIch 15y agoYou can write Flask applications without ever having heard of the term blueprint. I don't see how they could complicate things.
- rushabh 15y agoIf you are planning to have a lot of functionality, i.e. routings, you need some way to modularise. Bottle does seem to have a more pythonic way. Flask creates new concepts that seem counter intuitive to me at the first look.
- the_mitsuhiko 15y ago> Flask creates new concepts that seem counter intuitive to me at the first look. You don't have to use them. Just do the Bottle way if you prefer.
- DasIch 15y agoBottle has no concept at all for this, besides sticking independent applications together. You can do that with Flask as well, in fact the documentation there is an entire document describing various approaches[1]. Blueprints are a "new" concept but the approach is basically the same, however they are able to interact with the application at a Flask-level, they can modify the application and share information like the configuration. This is something Bottle doesn't support at a framework level, forcing you to abuse the functionality it provides from a semantical standpoint. This concept is more difficult to understand but than again it is very trivial compared to other concepts any web developer should grasp. [1]: http://flask.pocoo.org/docs/patterns/appdispatch/ http://flask.pocoo.org/docs/patterns/appdispatch/
- yashh 15y agoFlask is clearly a better framework than bottle. I started with bottle and hit a bug. (https://github.com/defnull/bottle/issues/192 https://github.com/defnull/bottle/issues/192). I had to switch to flask to avoid it.
- drivebyacct2 15y agoGod, this is ridiculous. I can't advance slides, when I do, it skips multiple slides at a time and I have to register to download a copy that I might actually be able to view.
- deleted 15y ago[deleted]