Hacker News new | past | comments | ask | show | jobs | submit login

Bottle and Flask are similiar and a great place to learn and start your journey with Python web application development. It is pseudo-minimalist though, so either you must almost immediately start reinventing the wheel to build basic stuff that you will need (as a novice developer I started by writing my own sessions and cookie handler).

The next realisation you'll come to is that all that stuff has already been written by someone else as addons. So you try that but eventually you'll find you are in so much pain from problems with integrating addons that you will realise that you would be best off with something that has all the basic functionality "batteries included". So then you'll try to find projects on github that have already baked together Flask plus all the plugins into a boilerplate project. Then you'll find that there's many ways to bake all that stuff together and start to wonder if maybe you're now using a framework. But the boilerplate Flask with addons integration doesn't feel like it has a really well thought out consistent overarching model.

So you'll then look at full featured integrated frameworks like Django where it's all integrated according to an architectural vision (perfect or otherwise is a matter of opinion) and although you might mot like some of the components, at least its all built in. Flask still carries of cruft and mental model though, because it is from earlier days of web development when you built the front end in the back end using things like Jinja templates.

And then one day you'll need to build just a simple REST API without all the bells and whistles needed in a web application. So you can then look at Falcon which is extremely minimalist for developer who know they don't want any extra web application stuff at all including things like back end UI generation with templates. It's a sharp knife because there's almost nothing in it, and never attempted to provide the features needed to build user oriented web applications, so it has a very small mental model to grasp.


Bottle and Flask are great for finding your feet in web development without being forced to learn too many concepts all at the same time.

Django or Pyramid or something full featured for web application development

Falcon for REST API development

If you are willing to take on the cognitive load of going straight to your destination, I would recommend beginners start with Django or Pyramid or Falcon. If (and this is entirely reasonable) you need to get going in Python web development without being overwhelmed by the concepts, go to Bottle or Flask but move on as soon as you can.

If you love Flask and have the skills and competence to craft your own architecture and carefully selected from a menu of addons that suit you and know how to whittle out unneeded functionality, then Flask is the right choice for you.

If your plan is to use Flask and use all the various add-ons to get Django-like levels of functionality out of the box, I think that's a mistake.

I worked on a pretty big Flask codebase (certainly bigger than the one mentioned in the article, though obviously it depends on how you define it, how you structure your codebase, etc). We didn't really use much in terms of third party add-ons, but we did fork and add various useful features, conveniences, etc. I don't personally think the lack of (eg) sessions is very painful, because it's trivial to implement, and there's something to be said for having a code path that you understand. Yes, we spent some time building some pretty generic stuff... but it was a tiny fraction of overall development time, and we gained wins from the fact that we understood our codebase very well thanks to it.

Definitely a balance to be struck, but I really appreciate that the surface area of Flask is small enough that provided you accept the basic conceptual model (request per thread, entry point is a function, etc), you have a lot of freedom to do what you will, and there's very little bias in the system pulling you away from that. Whereas if you don't want to do something the Django way... well, there's some cost to that choice, usually.

This is the first I've heard of Falcon. Have you used it for a "real" project? It'd be interesting to know the tradeoffs when considering it against something like Django Rest Framework. Looking at the benchmark figures on the Falcon site, it's sad that Python 3 underperforms Python 2. I wish Python 3 had the slightest performance win, it'd be an easier sell. Hate to shift the topic to Python 2/3 talks, but I've wanted to switch for a while now, and it's still not the simplest sell.

Yes I have used Falcon extensively and I like it alot.

Lies, damn lies and benchmarks - I'm not saying the benchmarks are made up but you know - the benchmark thing.

Falcon for REST API development. Django/Pyramid for full featured web application development.

And regarding speed, well how does its Python 3 performance compare to the Python 2 performance of other Python web servers? And any does speed matter that much? In many cases "fast enough is good enough" and the bottle necks are more likely to be other parts of your system and if speed matter that much then you should be horizontally scaling.

And if I may raise the ugly topic - who cares about Python 2 under any circumstances? For me - and I know many people do not think this way - Python 2 is dead so who gives a rats arse anything about it. Python 3 is the future and I'm not looking back for any gripes or grumbles about it.

Don't get me wrong, I think ruby-rails-slow is a bad thing, but Falcon fast should be good enough.

And if speed really matters to you then you shouldn't be using Python for web application development.

I looked into Falcon a while back - looked interesting but it wasn't immediately obvious what I would get over Flask (if nothing else, there's a tonne of Flask docs out there these days).

In all my research over the years Pyramid is the framework that looks the most interesting. The docs are amazing (I more or less read them cover to cover, even though I haven't tried the framework) and the whole thing seems very well thought out.

I'd love any insights from people who have worked with it.

I've worked on one project with Pyramid extensively, and I've been relatively pleased. It gives you a lot of flexibility, which can be good and bad. There is useful code that helps you unit test your app, and it is not a particularly opinionated framework. That being said, the number of options that pyramids allows can be a little overwhelming -- it gets a grade 'C-" when held up to the zen of python's line: "There should be one-- and preferably only one --obvious way to do it." When held up to "Although practicality beats purity.", as well as most of the rest of the pythonic ideals, Pyramids gets a solid A.

Personally, I'm excited to explore flask more, since it seems to put the ball entirely in your court. I like the concept behind flask a lot -- for some projects I'm willing to sacrifice additional framework features in exchange for a more careful understanding of everything I am adding to my app.

Yeah I mean it's hard to digest comments like "it's not a particularly opinionated framework" against things like "put the ball entirely in your court". They seem to be saying the same thing except you have a different perception of each when you say it.

The problem as I see it is that Pyramid has a lot of extra interfaces and support for things in the core by default (and some concepts that are completely missing from most frameworks like context). So much is there that it's easy to lose sight of how little is actually required. Fundamentally you can write Pyramid apps in 10 lines of code exactly as you would with Flask but that's less interesting for bigger apps and so the docs focus on all the extra features.

I mean if you take the example at the top of http://docs.pylonsproject.org/projects/pyramid/en/latest/ and add in the pyramid_jinja2 library via config.include('pyramid_jinja2') then you basically have views and jinja2 rendering fully baked.

As in the previous example if you get right down to it Pyramid doesn't even have a templating engine! Flask comes with jinja2 built-in! So scaling DOWN to APIs where this is not necessary is an interesting thing..

It's a matter of conceptual load, not about the actual capabilities. By "putting the ball in your court" I mean to say that flask adds an insignificant amount of conceptual load, and the overall difficulty to read and understand your app will be based on what you decide to add beyond flask.

By saying "it's not a particularly opinionated framework", I mean to say that it allows you to add, easily, whatever you want to it. However, there is a fair amount of conceptual load in doing so. The difference between a flask app and a pyramid app with pyramid jinja2 built in is that one of them takes about 20 seconds to understand.

Don't get me wrong -- I think pyramid is fantastic. But it it is disingenuous to suggest that there are not differences in complexity between the two frameworks.

You could always just use Werkzeug directly if you're just building an API.

"just building an API" does not mean you need something more lightweight. It means you have different requirements from a standard full stack web application. You are not dealing with cookies, forms or template rendering but you are still dealing with lots of other problems including authentication, authorization, headers, etc. Pyramid is the ONLY framework I've ever seen that comes with builtin support for dispatching to a view function based on more than just a request method (GET vs POST). In Pyramid GET vs POST is equivalent to any other request property including accept headers, cookies, query strings, etc. Any of these can dictate a different callable. See http://blog.delaguardia.com.mx/pyramid-view-configuration-le... for some examples.

That's really useful.

Well as one of the primary maintainers of Pyramid I'll just say that it's laughable to me all the comparisons to Django as it's much more similar to Flask. The main difference is that it comes with several more "pay only for what you eat" standardized interfaces that you can use to pull things together. It's declarative security concepts are fantastic and completely missing from most other frameworks as well which choose to punt this part to (usually) half-baked addon libraries built to serve one specific use-case.

>> it wasn't immediately obvious what I would get over Flask

Falcon gives you less than Flask, not more.

For me the big thing is that Falcon has none of the stuff needed for building web apps. Flask has all that stuff cause it was built when back end servers also built the HTML pages. There's alot of stuff associated with that functionality in Flask that is not there in Falcon. It makes it much cleaner.

I think you have that backwards. Python 3 has been dead in the water since it broke backward compatibility. It's slower. It still only has about 20% of Python 2's use. Most active development of software is still in Python 2. There hasn't been a single killer feature of Python 3 to justify breaking compatibility without deprecation. The Py3 Dictator has already had to back down once on "discontinuing" py2 which was supposed to happen in 2015. If he insists on preventing a smooth transition that doesn't require libraries and significant code change then he will just end up with a permanent split as PyPy, Cython or Conda take over Py2 maintenance.

I do not use DOS6 or Windows 3 or OS/2.

I'm interested in the present.

You of course may use whichever software you want but I don't have enough time to learn anything but what is currently being developed.

Most people did not use Windows ME or Windows Vista. Py3 is the ME/Vista of Python. A foisted inconvenience with little benefit. I still haven't heard anyone articulate a benefit other than "it's the future of Python!" Yeah, OK. But it certainly isn't the future of programming in Python until Guido makes an XP or 7.

Noooooo....let's not go there today! :-)

I'd take those benchmarks with a massive pinch of salt. 338┬Ás per request for Flask is the bad case. 0.5ms of the request is spent in the framework, that's not even noise. The fastest framework I've used is one I wrote for coldfusion and that's the only time I've expected all my requests to be sub 100ms. And even then, the network latency turns that into noise.

Look at features before performance - both in the case of frameworks and version of Python to use (Python 3 is a lot nicer).

I just added a comment up-thread with my experience in production with Falcon. Check it out.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact