Ask HN: Django vs Flask | Hacker News Reader

Ask HN: Django vs Flask

16 pointsrochak10 comments

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?

View on HN

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.

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.

I agree.

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.

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

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.

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.

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.

I gave a pretty detailed response here: 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/), which represents the data sent back and forth. And widgets, the HTML representation (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...).

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

Thanks for this incredible insight.

Reply on news.ycombinator.com