Python web micro-framework battle | Hacker News Reader

Python web micro-framework battle

slideshare.net

100 pointswhit53757 comments

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

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

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

Flask has the advantages of fast templates, strong WSGI features, serious unit testability at the app and library level, complete documentation...

Don'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. :)

but 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 presentation stated that templates were not part of the assessment criteria - since with most microframeworks template systems are either not bundled or easily replacable.

hey you're right, this wasn't very apparent from the slides.

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

You have to consider his primary use case (which he explains in the video). He's not writing web apps per se, but wrapping up existing python code in a simple http frontend. From that point of view I agree with him that bottle is quicker and easier to use than flask. That being said, flask is easily my go to framework for getting serious web app work done in python.

Great point. Interesting.

I did just this for a presentation:

https://bitbucket.org/mdg/cohpy-hips-presentation/src/89b3d2...

Bottle'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.

Comments 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."

You're right, I indulged in too much purple prose there. Sorry.

Would you expand on what you meant by:

> The context of the comment makes it seem like it's subpar on these things.

What I intended to get across was that Bottle, being a single file at ~2700 lines, makes it convenient to scan the code to see exactly what it is doing (or not). It also doesn't require a lot of typing to wire a function to a URL and offers some nice syntactic sugar while doing so: you don't have to @route things you can @get them or @post them (it's probably my Java background that makes me think in terms of separate code paths for the different HTTP verbs).

My take on a more detailed (and hopefully hyperbole-free) summation of my original post is:

"Because this was a short timeframe prototype, they had no Linux VM available in the lab so I had to use Windows. I found a recipe that let me run Python stuff as a service which I was able to wrap around Bottle more quickly than I was able to with the other frameworks I tried. Because I was working on a machine that had no access out to the internet, I had no virtualenv and had to instead bundle all my stuff up by hand."

Wow, great way to take criticism! Thank you.

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

Thanks 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. =)

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

Discounting 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/ has an extremely concise pyramid web app above the fold.

Indeed. The whole concept of when a framework starts or stops being micro is quite arbitrary.

Compare it with Bottle's version though and it doesn't look quite so concise any more: http://bottlepy.org/docs/dev/

Seems appropriate to link this here: https://docs.pylonsproject.org/projects/pyramid/1.2/designde...

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

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

The ordering of your patterns matters, so that is done at config time. However it's very common to want to have unrelated code executed depending on the type of request to a URL. Pyramid will do this lookup for you, rather than polluting a gigantic view function with multiple code-paths for distinct functionality.

    @view_config(route_name='hello', request_method='GET')
    def get_hello(request):
        return Response('a GET request for %s' % request.matchdict['name'])

    @view_config(route_name='hello', request_method='POST')
    def post_hello(request):
        return Response('stored info')

    config = Configurator()
    config.add_route('hello', '/hello/{name}')
    config.scan()
    app = config.make_wsgi_app()

Bottle and Flask actually allow for this too. Bottle's variant:

   @route('/hello/:name', method='GET')
   def hello_get(name):
       return 'Hello %s' % name

   @route('/hello/:name', method='POST')
   def hello_post(name):
       return 'Hello %s' % name

Pyramid permits a larger variety of predicates (including custom ones), however: https://docs.pylonsproject.org/projects/pyramid/1.2/narr/vie...

Yes but while implicit route ordering works a lot of the time, I'll gladly keep Pyramid's concept of explicit ordering, which is the main source of verbosity in the Pyramid setup which separates routes from views.

The order the decorators are run at import time is explicit. Everybody loves module-scope programming and import-time side-effects! What's wrong with you man? ;-)

I 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?

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

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

Those 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/) I get the following results:

    Flask      1467 LOC
    Jinja2     6560 LOC
    Werkzeug   9923 LOC
    Bottle     1910 LOC

(FWIW)

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

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

Flask also has more features and unless you find a way to accurately rate features for their usefulness and compare all those somehow the LOC metric has practically no meaning.

It would be much more interesting for potential users if people started comparing lines of documentation(LOD) and showed the quotient lines of tests/lines of code.

LOC and LOD suffer from the same problem: You can write (or generate) lots of code or documentation that does not help the user. You can even write docs that confuse the user, repeat a lot, to not get to the point and so on. In that case, more is even worse than less. There is no number to measure the usefulness of a framework or the quality of code. And there is no point in comparing frameworks just by numbers.

You will notice bad documentation almost immediately which makes the disadvantage of using LOD as a metric practically irrelevant.

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

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

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

You can write Flask applications without ever having heard of the term blueprint. I don't see how they could complicate things.

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

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

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

I did something similar a while back, in case any-one's still interested ..

https://github.com/agiliq/so-starving

Flask is clearly a better framework than bottle. I started with bottle and hit a bug. (https://github.com/defnull/bottle/issues/192). I had to switch to flask to avoid it.

The video is also available at http://www.youtube.com/PyconAU#p/u/7/AYjPIMe0BhA

Interesting if somewhat very biased.

Where does one draw the distinction between micro- and megaframeworks? Or, for that reference, just a "framework"?

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

> 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

Things 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 ;-)

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

Pesto wins if you count the extra features at the end.

tl;dr: Bottle wins.

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

God, 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.

Reply on news.ycombinator.com