8 ms·

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't get me wrong; I love Flask. It launched me into web development with Python at a time when Django only confused me. But I just can't justify using Flask for a big project anymore when Django is just so much faster to work with (for me). If I need to, I can customize nearly any part of Django I want, store it as a project template, and use `django-admin startproject myproject --template="https://sometemplate.com/in/a/git/repo.git" https://sometemplate.com/in/a/git/repo.git" ` to start a new project with it.

bliti 11y ago
I work with both Django and Flask too. The difference is that with Flask you have the flexibility of doing things your way. Useful for systems that don't fit the typical CRUD architecture.
tedmiston 11y ago
> I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django This exactly. Every site I've attempted to build in Flask ends up having so many dependencies for even the simplest of things. I shouldn't have to go and find what the most popular recent library for each aspect is (even if they are out there and are great). Once you learn Django, it's just so much faster to work in from the maturity of the framework itself to the docs to the community. That said I do have one project today I keep in Flask. It's a small personal website which serves a few templated pages, has a very small content database, and just a couple API endpoints used privately. In all it may be a couple hundred lines of code.
mrharrison 11y ago
Yes I couldn't agree more. I've used both Flask and Django, and with Flask you just recreate everything in Django. Plus the Django community is more vibrant and the Django docs are super good.
dorfsmay 11y ago
Interestingly, I went the other way around, did a toy project with django, hated the ORM, didn't like the template so much, and at the tolime django didn't support python 3. I then discovered bottlepy sqlalchemy base (so I write raw SQL, but I can easily switch database underneath), and mako templates, and was in a much better place. I have also worked in flask environments, flask does have the advantage of having a bigger plugin ecosystem, and a bigger network effect (way more users!), which translate in more recipes, entries on SO, etc...
raziel2p 11y ago
I won't disagree when it comes to authentication and admin interface, but test suites (pytest), an ORM (SQLAlchemy), and migrations (Alembic) are not very hard to set up. Furthermore, you can use them in other non-frameworked projects. Of course, it's hard to build something like an authentication/admin interface framework without there being some standardized ORM/migration system, so the argument is more or less moot.
siddhant 11y ago
Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case). It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working on. And it worked out really well, especially after I combined it with SQLAlchemy and Alembic. 80% of the feature set right there. And SQLAlchemy is such a fantastic toolkit. I'm hoping that django channels (http://channels.readthedocs.org/en/latest/ http://channels.readthedocs.org/en/latest/) stabilizes soon.
- Beltiras 11y ago
  The Django community knows full well that this is a missing feature in modern web development. There was a talk featuring this topic at DUTH this fall. https://opbeat.com/events/duth/#twisted-and-django https://opbeat.com/events/duth/#twisted-and-django
- jonwayne 11y ago
  The whole "WSGI revision" effort is intended to solve the problem of websockets (and HTTP 2.0) across frameworks and servers.
- jkarneges 11y ago
  I prefer to split a server app into a connection management layer and a backend logic layer. This way the backend can remain stateless which makes for easier maintenance. I use Django as the backend piece in most of my realtime apps (for example WebhookInbox) and it works great. Of course, native support for long-lived connections in Django would be cool, if only because it would mean the connection management layer could be built with Django too.
lucian1900 11y ago
If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.
- johnmaguire2013 11y ago
  Why not just use SQLAlchemy with Django and ignore the built-in ORM?
  - collyw 11y ago
    Because the Admin and other features won't work?
    - true_religion 11y ago
      In order to get the admin and other features, all you need to do is define your models in Django's system. After that you can use SqlAlechemy as a side channel, just like a lot of people use NoSQL databases.
- ivoras 11y ago
  Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?
  - collyw 11y ago
    Conditional aggregates were a problem until 1.8 or 1.9. Joins on more that one field would be another.
  - lucian1900 11y ago
    Arbitrary explicit joins make a lot of data reporting much easier.
CuriouslyC 11y ago
This is mostly true if your application is mostly CRUD with HTML endpoints (the use case Django was designed for), particularly very "solved" use cases like blogs. (As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself) If your application is mostly endpoints that do "interesting" stuff, you aren't going to hit much of the Django infrastructure, and piece you are most likely to hit (the ORM) is so far behind the dominant Python ORM (SQLAlchemy) that it is just painful. Flask is a lot better at getting "out of your way" than Django. The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base.
- wcarss 11y ago
  > The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base. I wholeheartedly agree! Do you have any resources in mind (even perhaps not specific to flask) that you think would be useful to people hitting that wall?
  - mixmastamyk 11y ago
    These came up last week: https://etscrivner.github.io/posts/2014/10/building-large-flask-apps-in-the-real-world/ https://etscrivner.github.io/posts/2014/10/building-large-fl... https://news.ycombinator.com/item?id=11121355 https://news.ycombinator.com/item?id=11121355
pbreit 11y ago
This is mostly my experience as somewhat of a newbie. Every project I contemplate needs user accounts and admin. And db access & migrations make development so much easier. I guess if there was a solid recommendation on what Flask components/addons would be good to use for a "regular" web site, Id be OK. Otherwise, it ends up being so much more comfortable to go "full stack".

bliti 11y ago

I work with both Django and Flask too. The difference is that with Flask you have the flexibility of doing things your way. Useful for systems that don't fit the typical CRUD architecture.

tedmiston 11y ago

> I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django This exactly. Every site I've attempted to build in Flask ends up having so many dependencies for even the simplest of things. I shouldn't have to go and find what the most popular recent library for each aspect is (even if they are out there and are great). Once you learn Django, it's just so much faster to work in from the maturity of the framework itself to the docs to the community. That said I do have one project today I keep in Flask. It's a small personal website which serves a few templated pages, has a very small content database, and just a couple API endpoints used privately. In all it may be a couple hundred lines of code.

mrharrison 11y ago

Yes I couldn't agree more. I've used both Flask and Django, and with Flask you just recreate everything in Django. Plus the Django community is more vibrant and the Django docs are super good.

dorfsmay 11y ago

Interestingly, I went the other way around, did a toy project with django, hated the ORM, didn't like the template so much, and at the tolime django didn't support python 3. I then discovered bottlepy sqlalchemy base (so I write raw SQL, but I can easily switch database underneath), and mako templates, and was in a much better place. I have also worked in flask environments, flask does have the advantage of having a bigger plugin ecosystem, and a bigger network effect (way more users!), which translate in more recipes, entries on SO, etc...

raziel2p 11y ago

I won't disagree when it comes to authentication and admin interface, but test suites (pytest), an ORM (SQLAlchemy), and migrations (Alembic) are not very hard to set up. Furthermore, you can use them in other non-frameworked projects. Of course, it's hard to build something like an authentication/admin interface framework without there being some standardized ORM/migration system, so the argument is more or less moot.

siddhant 11y ago

Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case). It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working on. And it worked out really well, especially after I combined it with SQLAlchemy and Alembic. 80% of the feature set right there. And SQLAlchemy is such a fantastic toolkit. I'm hoping that django channels (http://channels.readthedocs.org/en/latest/ http://channels.readthedocs.org/en/latest/) stabilizes soon.

Beltiras 11y ago
The Django community knows full well that this is a missing feature in modern web development. There was a talk featuring this topic at DUTH this fall. https://opbeat.com/events/duth/#twisted-and-django https://opbeat.com/events/duth/#twisted-and-django
jonwayne 11y ago
The whole "WSGI revision" effort is intended to solve the problem of websockets (and HTTP 2.0) across frameworks and servers.
jkarneges 11y ago
I prefer to split a server app into a connection management layer and a backend logic layer. This way the backend can remain stateless which makes for easier maintenance. I use Django as the backend piece in most of my realtime apps (for example WebhookInbox) and it works great. Of course, native support for long-lived connections in Django would be cool, if only because it would mean the connection management layer could be built with Django too.

lucian1900 11y ago

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

johnmaguire2013 11y ago
Why not just use SQLAlchemy with Django and ignore the built-in ORM?
- collyw 11y ago
  Because the Admin and other features won't work?
  - true_religion 11y ago
    In order to get the admin and other features, all you need to do is define your models in Django's system. After that you can use SqlAlechemy as a side channel, just like a lot of people use NoSQL databases.
ivoras 11y ago
Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?
- collyw 11y ago
  Conditional aggregates were a problem until 1.8 or 1.9. Joins on more that one field would be another.
- lucian1900 11y ago
  Arbitrary explicit joins make a lot of data reporting much easier.

CuriouslyC 11y ago

This is mostly true if your application is mostly CRUD with HTML endpoints (the use case Django was designed for), particularly very "solved" use cases like blogs. (As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself) If your application is mostly endpoints that do "interesting" stuff, you aren't going to hit much of the Django infrastructure, and piece you are most likely to hit (the ORM) is so far behind the dominant Python ORM (SQLAlchemy) that it is just painful. Flask is a lot better at getting "out of your way" than Django. The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base.

wcarss 11y ago
> The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base. I wholeheartedly agree! Do you have any resources in mind (even perhaps not specific to flask) that you think would be useful to people hitting that wall?
- mixmastamyk 11y ago
  These came up last week: https://etscrivner.github.io/posts/2014/10/building-large-flask-apps-in-the-real-world/ https://etscrivner.github.io/posts/2014/10/building-large-fl... https://news.ycombinator.com/item?id=11121355 https://news.ycombinator.com/item?id=11121355

pbreit 11y ago

This is mostly my experience as somewhat of a newbie. Every project I contemplate needs user accounts and admin. And db access & migrations make development so much easier. I guess if there was a solid recommendation on what Flask components/addons would be good to use for a "regular" web site, Id be OK. Otherwise, it ends up being so much more comfortable to go "full stack".