Hacker News Reader

Comment by ryannevius | Hacker News Reader

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" ` to start a new project with it.

View on HN

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.

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

These came up last week:

https://etscrivner.github.io/posts/2014/10/building-large-fl...

https://news.ycombinator.com/item?id=11121355

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

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/) stabilizes soon.

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

The whole "WSGI revision" effort is intended to solve the problem of websockets (and HTTP 2.0) across frameworks and servers.

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.

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

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.

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.

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.

Why not just use SQLAlchemy with Django and ignore the built-in ORM?

Because the Admin and other features won't work?

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.

Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?

Conditional aggregates were a problem until 1.8 or 1.9. Joins on more that one field would be another.

Arbitrary explicit joins make a lot of data reporting much easier.

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.

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

Reply on news.ycombinator.com