
Ask HN: Django vs Flask - rochak
I have done a lot of web development in Django and am really a fan of the framework, especially the Django REST framework. What really surprised me was that many of my colleagues were using Flask for the same. So, I decided to check it out. From glancing over the docs, I realised that it is just an extremely fast way of getting started with the development as opposed to a lot of time required by Django - as claimed by many websites and blogs. However, I fail to see what other occasions one would use Flask over Django for developing the website. Are there any other specific areas where one would prefer one over the other?
======
sharmi
I agree with what git-pull has commented.

In addition to that, addressing your question:

* There is value in reusing the tool that you have already used, whether django or flask, because you have accumulated knowledge for doing the common stuff that you can carry from one project to the other trivially, and spend the bulk of your time and what really matters for that project.

* IMO, Flask is most suitable for educating oneself on how a web app is structured and what it's crucial features are. With Django, I can only focus on the aspects of the project that matter, and all other bases like security, scalability etc are covered by the django codebase, atleast as long as one follows the best practices.

Also, only override existing django parts, if you need to, not because you
can. The obligatory anecdote: For one of my projects, I decided Jinja2 was
much better than django Templates and switched to Jinja2. And true, the
Jinja2's syntax was more versatile than Django Template's. Unfortunately, it
took me sometime to realize that by doing the switch, I also lost the ability
to use hundreds of plugins for django-template because either they do not
interact with Jinja2, or they do so poorly. For a later project, I stuck to
django-templates and with a little diligence, I could make it do all that
Jinja2 could do too (atleast those features that I found desirable in Jinja2).
Never, never, never add unnecessary complication to a project that needs to be
shipped.

~~~
meric
I also think django templates is not up to par in 2017, and use typically
Django as an REST API platform; A node/react server would call the API and
render the html.

------
eggie5
I don't think the two are comparable. Django is a full featured and
opinionated MVC web framework, while Flask is a much more simple library to
handle web apps.

I think flask has it's place for narrow-scoped projects like some type of API
server while Django's use case is very clear: a web monolith.

------
sharmi
Also, if you are interested in implementing a simplr webserver by yourself,
check aosa book chapter [http://aosabook.org/en/500L/a-simple-web-
server.html](http://aosabook.org/en/500L/a-simple-web-server.html)

------
borplk
It's just a micro-framework so it's useful if you often use Django but end up
replacing all sorts of bits and pieces of it anyway. In a case like that you
can be better off just using Flask.

------
bjourne
I've used both extensively. In my opinion Flask is more suitable if you want
everything to be exactly how you want it to be. A Django project won't ever be
as clean and minimal as a Flask project. However, if your focus is on getting
shit done and delivering stuff then Django is much better. Especially django-
admin is a very practical tool.

Caveat emptor: It was about three years since I used the frameworks last and
much can have changed in that time.

~~~
knicholes
I don't understand why people care about minimal backend web frameworks. In my
experience when people choose Flask for a large project, they end up writing
much of the stuff that is already included with Django, but poorly and with no
documentation.

------
tony
I gave a pretty detailed response here:
[https://news.ycombinator.com/item?id=14026051](https://news.ycombinator.com/item?id=14026051)

\- Django may be "batteries included", but definitely _not_ monolithic. It's
your choice how you want to implement views. Nothing's tying you down to using
a DetailView, but by conforming to them, you make your code more readable and
consistent.

You can also pick your own template system, like Jinja2, but django templates
are still fast, intuitive, and powerful. You don't have to pull in _every_
contrib module and CBV. You don't have to use django.forms, but they save a
lot of time with form validation. You don't have to use ModelForm (ORM-backed
forms), but it gives you the ability to get database-backed form behavior with
little work. They're also designed to be customizable for specialized
scenarios.

Django is designed from the ground up to let you override and expand.
django.forms build upon the "field" API
([https://docs.djangoproject.com/en/1.11/ref/forms/fields/](https://docs.djangoproject.com/en/1.11/ref/forms/fields/)),
which represents the data sent back and forth. And widgets, the HTML
representation
([https://docs.djangoproject.com/en/1.11/ref/forms/widgets/](https://docs.djangoproject.com/en/1.11/ref/forms/widgets/)).
You can use django, and build your own fields and widgets to use with forms.

You don't have to load every template tag and filter library. It's
configurable on a per-template (per-file) basis. You don't have to use the
auth system, but if you do, you can still use a custom User model and backend
([https://docs.djangoproject.com/en/1.11/topics/auth/customizi...](https://docs.djangoproject.com/en/1.11/topics/auth/customizing/)).

But you're going to have to conform to some sensible conventions (such as a
settings modules, urls.py, request contexts). In most situations, you'll pull
in stuff from django.contrib, like django.contrib.auth, and occasionally
you'll write your own custom replacements.

And you'll end up using the ORM.

\- While it's not SQLAlchemy, Django's ORM is capable. It may not have as many
bells and whistles, but Django ORM is not "weaker" in any sense. It's been
used in production for 10+ years and works across SQL dialects. In a pinch,
one-off custom queries have.raw(), and I could still run those safely thanks
to params
([https://docs.djangoproject.com/en/1.11/topics/db/sql/#passin...](https://docs.djangoproject.com/en/1.11/topics/db/sql/#passing-
parameters-into-raw)). Also, the migration system is nice.

\- While development settings can be slow when you're using asset managers
(like django-compressor), Django _can_ scale. Of course if you're rebuilding
SASS every refresh and not using cache, you're going to have 500ms to 1 second
page loads that can be cringey if you're hauling in bootstrap. But in
practice, you're going to be compressing those files in production and using
caching settings.

\- Testing can be fast. My favorite tool is RequestFactory
([https://docs.djangoproject.com/en/1.11/topics/testing/advanc...](https://docs.djangoproject.com/en/1.11/topics/testing/advanced/#the-
request-factory)). I could run about 100+ tests in about 300ms. So every time
I saved, I checked the permissions/integrity of all my views, including ones
which used the ORM.

~~~
rochak
Thanks for this incredible insight.

