Ask HN: Django vs. Flask
1–10 of 22 posts
Re: Ask HN: Django vs. Flask
#2Re: Ask HN: Django vs. Flask
#3But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it (https://github.com/mitsuhiko/flask-sqlalchemy/pull/250, yes I'm in the thread).
You'll fork it or brew your own code to get declarative models working right. Kinda time consuming, but at least your models can be pulled in by any python code, and aren't tied down to a framework (That's what you were avoiding from the first place, wasn't it?)
Then you'll pick up WTForms (https://wtforms.readthedocs.io/en/latest/), another excellent library. And you'll miss having Django ORM's rich form and model-backed validation. So you'll try wtforms-alchemy, https://github.com/kvesteri/wtforms-alchemy.
Then you'll begin to see why Django makes sense after using Flask for a while. Django pulls in all the essential stuff and supports it well.
And top of that, django's addons like django-extensions (https://django-extensions.readthedocs.io), which gives you Werkzeug's debugger if you use ./manage.py runserver_plus. And ./manage.py shell_plus, which integrates with ptpython/ipython/bpython (https://django-extensions.readthedocs.io/en/latest/shell_plu...).
Django rest framework, DRF for short (http://www.django-rest-framework.org/), which is very mature at this stage, runs circles around Flask API. Flask API is inspired by DRF. You could also try https://flask-restful.readthedocs.io, but after all that, you'll be missing that tight model support.
You'll love flask. The code is top tier and exemplary. The testsuites are a dream and are very clear. Documentation is awesome. It feels good to code in it. But django feels good to code in as well.
Django's ORM is very mature. It's easier than SQLAlchemy, and despite SQLAlchemy's purity, and documentation - even better than flask's - Django's ORM does the trick for pretty much anything, even foreign databases I've interacted with. Another thing, QuerySet's are a charm, a lot of django's addons like django-filters, django-rest-framework and django-tables2 are built on top of its versatility.
Another thing Flask community ends up having to clone from Django is django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar. See https://flask-debugtoolbar.readthedocs.io.
Again, I love flask, but when I realized that I'm just going to end up reinventing django with my flask app anyway, I started going with django on new projects. I haven't turned back, but still check out flask and sqlalchemy to see what's happening now and then.
Re: Ask HN: Django vs. Flask
#4You can get pretty far with Flask. You'll need an ORM, so you'll likely chuck SQLAlchemy in. Then you'll want easier access to SQLAlchemy, sorta like, you know, django does it, so you pick up https://github.com/mitsuhiko/flask-sqlalchemy . But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it ( https://github.com/mitsuhiko/flask-sqlalchemy/pull/250 , yes…
Re: Ask HN: Django vs. Flask
#5Flask for learning from the ground up. Django after coming to the realization that large Flask projects end up cobbling together 80% of what Django offers, usually poorly.
Re: Ask HN: Django vs. Flask
#6You can get pretty far with Flask. You'll need an ORM, so you'll likely chuck SQLAlchemy in. Then you'll want easier access to SQLAlchemy, sorta like, you know, django does it, so you pick up https://github.com/mitsuhiko/flask-sqlalchemy . But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it ( https://github.com/mitsuhiko/flask-sqlalchemy/pull/250 , yes…
I think the first objection one would raise is that you don't need an ORM at all. It all depends on the application, of course, but ORM means giving up a lot of control (and transparency, and understanding) of your database in exchange for a few shortcuts regarding things like M:M links.
Use an ORM because tools like this: https://marshmallow.readthedocs.io/en/latest/ work really well with it.
And tools for migrations: https://sqlalchemy-migrate.readthedocs.io/en/latest/ start to make sense in your code.
You don't need an ORM to do either of those things, but it makes things a hell of a lot more organized. Makes the database easy to understand from your code. Makes things like "testing from a blank database" really nice.
You don't ever _need_ an ORM, but for 90% of projects you'll use Flask and a Database for, it makes your life a lot nicer.
Re: Ask HN: Django vs. Flask
#7I can see using Django to rapidly prototype some kind of CRUD app, but on the other hand, you could just use Wordpress for that. Flask seems like it would be a superior platform for engineering anything non-trivial, especially if you care about how it works.
Re: Ask HN: Django vs. Flask
#8You can get pretty far with Flask. You'll need an ORM, so you'll likely chuck SQLAlchemy in. Then you'll want easier access to SQLAlchemy, sorta like, you know, django does it, so you pick up https://github.com/mitsuhiko/flask-sqlalchemy . But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it ( https://github.com/mitsuhiko/flask-sqlalchemy/pull/250 , yes…
> Django rest framework, DRF for short (http://www.django-rest-framework.org/), which is very mature at this stage, runs circles around Flask API. Flask API is inspired by DRF.
I use both and enjoy both, but Flask API is _much_ better designed than DRF. Go look over the source for both.
So yeah, Flask is much smaller than Django: but that's a good thing _for some projects_ like you've said. If you want Django manage.py, Django's ORM, DRF, and debug toolbar, then use Django!
Re: Ask HN: Django vs. Flask
#9It depends on the application. Do you care about how things work inside your database? Do you want to understand how the subsystems of your app (like authentication, security, the API, etc) work? Flask allows you (and forces you) to make your choices explicit. Django makes the decisions for you and hides its workings under layers of abstraction. I can see using Django to rapidly prototype some kind of CRUD app, but o…
I feel like I'm replying a lot in this thread!
I think it's the other way around. If you want to QUICKLY prototype something, use Flask: it's light weight, and your app will _literally_ be one hundred-line file + some templates.
If you know you're going to use much of the common Django tools, use Django. Django projects are usually harder to spin up in my experience.
I wouldn't relate Django to Wordpress at all. It'd be tough to get a Wordpress type platform from scratch in Django OR Flask.
Re: Ask HN: Django vs. Flask
#10You can get pretty far with Flask. You'll need an ORM, so you'll likely chuck SQLAlchemy in. Then you'll want easier access to SQLAlchemy, sorta like, you know, django does it, so you pick up https://github.com/mitsuhiko/flask-sqlalchemy . But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it ( https://github.com/mitsuhiko/flask-sqlalchemy/pull/250 , yes…
I think the first objection one would raise is that you don't need an ORM at all. It all depends on the application, of course, but ORM means giving up a lot of control (and transparency, and understanding) of your database in exchange for a few shortcuts regarding things like M:M links.
In fact I'm coming short on a value equation where it'd be more secure / efficient / readable without at least a query builder.
> but ORM means giving up a lot of control
What control is being lost, specifically?
> (and transparency, and understanding)
Highly recommend Django in Depth by James Bennett at PyCon 2015. https://www.youtube.com/watch?v=tkwZ1jG3XgA
Also, try out printing the .query of the QuerySet:
print(MyUser.objects.all().query)
SELECT "core_myuser"."id", "core_myuser"."password", "core_myuser"."last_login", "core_myuser"."is_superuser", "core_myuser"."username", "core_myuser"."email", "core_myuser"."is_active", "core_myuser"."is_admin" FROM "core_myuser"
And Q(), https://docs.djangoproject.com/en/1.11/topics/db/queries/#co..., .extra(), https://docs.djangoproject.com/en/1.11/ref/models/querysets/..., and finally raw SQL queries https://docs.djangoproject.com/en/1.11/topics/db/sql/.
> of your database in exchange for a few shortcuts regarding things like M:M links.
Maybe a few other benefits: helps with readability, consistent with OOP in python. Works across SQL dialects. Prevents mistakes, since those relationships are common. Getting clear and consistent access to common data retrieval and updating.