HN Explorer

Ask HN: What's the state of Python web frameworks in 2015?

24 points by trjordan ↗ HN
Hey HN,

I'm currently starting on a new project, and the last time I thought about different Python frameworks, it was 2011. It was a different world: Python3 was well and truly scary, Pylons / Pyramid was confusing, and for some reason, nobody I knew had heard of Flask.

I was a full-time Python programmer for a few years, but I got distracted in the last couple of years doing sales and marketing. As a result, I lost touch with a lot of trends and hipness in Python. Can you help me figure out what's changed and/or what's worth considering that might not be on various projects home pages?

Here's some of the bounds I'm working with:

- I think it's time for Python3, so that's what I'm rolling with.

- I LOVE LOVE LOVE SQLAlchemy. So, whatever I pick, I'd like SQLAlchemy to be a 1st class citizen in that world.

- I believe in monolithic first. Yes, at some point, I'm sure this will be a bunch of microservices. But right now, there's only me. And...

- The web app isn't the only thing here. I'll be writing a bunch of code that's not framework-specific or even web-facing, and I'll tie that into the web framework to display it.

For no particular reason, I'm leaning towards Flask. I've worked with Django, and it's a little overbearing for my taste.

What should I know? Links to any recent comparisons that you think are well-considered would be incredibly appreciated.

(PS Are you in the Bay Area and want to think about marketing data and visualization? Ping me: tr@scortex.co)

20 comments

[ 3.5 ms ] story [ 54.5 ms ] thread
codegeek
I would say go with Flask specially based on some of the things you said. Let me elaborate:

- SQLAlchemy. Flask integrates very well with SQLAlchemy and has a great extension for it as well (Flask-SQlAlchemy).

- "code that's not framework-specific ". Flask is a winner here being micro and you can even build lovely APIs on top of it.

- Even though core flask is minimal by design, it now has a matured ecosystem of awesome extensions that lets you rapidly build apps as you need. The beauty is that you are not restricted to one specific way of doing something. Flexibility but that also means you have to make more decisions.

Django is great as well but like you said, it is a much bigger framework and more opinionated. Nothing wrong with it but for building large applications, I prefer Flask due to its micro-ness and flexibility.

trjordan
Cool, glad to hear I'm not crazy. Thanks!
vonseel
I would stick with Django. It has matured significantly in the past few years, and you don't have to write a single Django form/view if you don't want. DRF and the Django ORM are great , integrate with your own non-Django Python code and other backends as you wish.
avinassh
But OP likes SQLAlchemy. SQLAlchemy and Django doesn't go well together.
trjordan
Yeah, I don't think I can go Django. The ORM works well enough, but SQLAlchemy is my jam.
simon_acca
If your design is a Single Page WebApp + Backend API I would recommend you to take a look at The Falcon Framework ( http://falconframework.org/ ).

  - it certainly integrates with SQLAlchemy
  - it's a small codebase you can navigate quickly
  - it's a Rackspace community project
  - it's fast and well tested
Flask is also a good choice since it's popularity ( which leads to lots of plugins and a more stable code).
avinassh
Falcon seems interesting. But why did specifically mention about Single Page Web App?
1arity
probably because falcon is for building APIs which are a workable pattern with a single page app which has a thick client and treats the server only as an asynchronously returning data store.
antod
Being that Django isn't to taste and you love SQLAlchemy (I have the same biases), I reckon Flask and Pyramid would be the best choices these days.

They are both non opinionated frameworks that do well with bringing in external code. I think both frameworks have opinionated/specialised 'metaframeworks' (eg Kotti or Eve) available though for those that don't want to make too many architecture or library choices.

If I had to differentiate between Flask and Pyramid, I would say that Flask has a slight edge for getting projects up and running while Pyramid is a bit better for projects that will grow and increase in complexity.

Or another way, Flask leans towards just getting stuff done (Hackers) while Pyramid leans towards enabling clean architectures (Software Engineers).

But there is a huge overlap in those characterisations - Pyramid is still great for getting stuff done and Flask is still great for cleanly architecting stuff.

Flask seems to be better known though and have more users, while Pyramid seems to have better release momentum lately. Those are probably the few objective advantages either has over the other.

trjordan
Interesting to hear about Pyramid. I'd always gotten the feeling that Flask was a bit lighter-weight.

I think I'm going to steer clear of Pyramid because 1) I worked with it before, and want to try something new-ish and 2) I ended up fighting with a bunch of the defaults in Pylons / Pyramid. I think they got more sane over time, but I get the feeling that Pyramid devs and I would get along, but do things like finish each others sentences with the wrong thing. "Do you know what would go perfectly with this dinner?" "Yes, beer!" "... er, I was thinking coke. But, yeah, beer would work, too, I guess."

If nothing else, I'm glad to hear those two are the top of your list. I'm feel like I "get" what both of them want you to do, which helps me (personally) a ton.

mattwritescode
Flask or Django would be good options.

Django is very modular so you can pull out or change the bits you do not like (templating you can use jinja, orm you can exchange for sqlalchmey).

Flask, you build what you want (enough said).

iurisilvio
If you are removing Django templating and ORM, it makes completely sense to use something else.

Flask is an awesome option, I'm building things with it for some years now.

imauld
I have to agree with iurisilvio here.

If you are pulling out the Django templates and the ORM you should just use Flask. You shouldn't choose a framework and then immediately start taking it apart if there is an alternative that comes the way you want basically out of the box.

[dead] d_luaz
I choose Flask because it's lightweight with good plugin support (especially SQLAlchemy).

Do share what stacks you guys are using and why you are using them: http://www.stackbus.com/ (FYI, I build it)

nicholas73
How is web2py doing?
karuth
I tried web2py a little bit. I liked the fact that a lot of basic things get setup initially. But all the globals confused the heck out of me. Couldn't quite understand the right way to test. It could be just me though!

I am happy using Flask these days!

nicholas73
Agree about the globals - for something that's touted as quick and easy for beginners, I spent an inordinate time in the docs due to all the automagic features. Customizing something like a form outside the automagic prescription is also a non-intuitive pain.

That said, there are many things I do like about it. Mainly that it's out of the box for App Engine, unlike Django, and its web-based IDE built in.

dafrankenstein2
Use flask but also keep django with you. Sometimes django may come handy working with big-scaling enterprise webapp.
trjordan
Cool, thanks for the thoughts. I'm going to go with Flask: my 24-hours-in opinion is that I can work with this, and it's got enough community support to make the easy things easy. I haven't done logins or much more with sqlalchemy-flask, but they seem good.

I'm a little worried the flask plugins are thin. As with anything where you have lots of flexibility, you can stub your toes if you don't know the "right" way to do it. For example, I tried to use flask-assets and pyscss to compile sass, but I found a bug in pyscss pretty quickly and had to back out and switch to the Ruby implementation of sass. Not ultimately a big deal, and the whole thing was up and running in about 3 hours.

EDIT: Ugh, more pain with Flask plugins. Flask-SQLAlchemy assumes you're going to declare models that won't be used outside of the web context ... so you can't separate your models from Flask. Annoying! Getting fixed here: https://github.com/mitsuhiko/flask-sqlalchemy/pull/250

So, anyway, that's what I'm going to do! Thanks for all your input!

karuth
Well there are work around options to the restriction with SQLAlchemy that you mention here.

You can use SQLAlchemy core instead of ORM and write your models independent of web context.

Check out https://github.com/gouthambs/flask-blogging

for example!