

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

Hey HN,<p>I&#x27;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 &#x2F; Pyramid was confusing, and for some reason, nobody I knew had heard of Flask.<p>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&#x27;s changed and&#x2F;or what&#x27;s worth considering that might not be on various projects home pages?<p>Here&#x27;s some of the bounds I&#x27;m working with:<p>- I think it&#x27;s time for Python3, so that&#x27;s what I&#x27;m rolling with.<p>- I LOVE LOVE LOVE SQLAlchemy. So, whatever I pick, I&#x27;d like SQLAlchemy to be a 1st class citizen in that world.<p>- I believe in monolithic first. Yes, at some point, I&#x27;m sure this will be a bunch of microservices. But right now, there&#x27;s only me. And...<p>- The web app isn&#x27;t the only thing here. I&#x27;ll be writing a bunch of code that&#x27;s not framework-specific or even web-facing, and I&#x27;ll tie that into the web framework to display it.<p>For no particular reason, I&#x27;m leaning towards Flask. I&#x27;ve worked with Django, and it&#x27;s a little overbearing for my taste.<p>What should I know? Links to any recent comparisons that you think are well-considered would be incredibly appreciated.<p>(PS Are you in the Bay Area and want to think about marketing data and visualization? Ping me: tr@scortex.co)
======
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!

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

------
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](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](https://github.com/gouthambs/flask-blogging)

for example!

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

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

------
dafrankenstein2
Use flask but also keep django with you. Sometimes django may come handy
working with big-scaling enterprise webapp.

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

