I've seen this opinion on HN for years, but still don't _really_ understand it. Our cofounder built what is now a $1B+ SaSS company from some cursory SQL knowledge he gained while interning at a hospital in the early 2010's. The entire business is, in essence, a fancy graphical UI around postgres.
I've now been writing django at work for five years and still have yet to come across a query builder/orm which is as powerful yet simple in addition to being a breeze to on-board new engineers with.
When there are queries that require the use of non-django builtins, it's also relatively easy to use django raw sql or just straight up use the psycopg2 sql.SQL dynamic string composition helpers.
With the complexity of some our chained django QueryMethods, the company would have quite literally been impossible to build without django's query builder, at the very least.
This is a double-edged sword in my opinion. The Django ORM is among my favourite ORMs, but the abstraction (like any) can cause problems over time.
At scale, poorly understood ORM-generated queries can be a real pain, especially if your team's SQL skills have atrophied due to over-reliance on the ORM.
As an exercise, I'd possibly recommend reviewing your top 1-3 worst performing queries, tracking them back to the ORM, and evaluating how to improve them.
I completely agree, except for the last line. It is in my experience very hard to post-hoc get people to care about query performance. Organizationally and technically. In a complicated monolith at scale, de-tangling the ORM is a multi-years long project.
Edited to say: as for the average website, I do completely agree. For the unique website that will scale as well, I likely would still 95/100 recommend the ORM, but my experience has taught me that there be some pain on the road.
Are people still using a mature, stable, battle-tested framework with tons of third-party resources, great documentation and excellent coverage of many business needs ?
Not to be condescending or patronizing, but, well, I'm answering your question and it itself has a dismissive tone.
Yes, people are still using Django.
As I've grown in my career, frameworks, libraries, and architectural patterns just become tools. I don't quite understand folks who identify as a "React developer", or a "Django developer". When evaluating any framework, you must learn to eschew the latest hotness long enough to evaluate what your requirements are, and maybe most importantly, what your constraints are.
For a surprising amount of projects today, I would still recommend Django above anything else.
After a few years around the block (meteor, next.js), I'm back to Django. Got an mvp planetary web map annotation app up in no time, using Django DRF and just some plain hand-written js. Feels great to be back.
A lot. And it baffles me why hasn't anyone realized that Kenneth Reitz was right about django over a decade ago and all his points are equally valid today.
I will take a well curated package that handles all the problems for me rather than bolting together pieces just so I can feel more ownership of a project.
- Admin panel? Django has me
- Web forms? Django has me
- Testing? Django, again has an out of the box solution
- Latest in security practices[0]? Again, covered for free
Flask, boy oh boy. I want an ORM? Guess I have to search around, Flask-SQLAlchemy has a lot of hits, I guess? Emails? Well, the Flask Mega-Tutorial uses Flask-Mail[1], guess I will use that. Oh look, it has not been updated since 2014[2]. Hope there is not a security flaw in there[3].
Django follows best practices, and has a huge community ensuring that there is adequate coverage and features required for modern development.
FastAPI is the better choice now as its ecosystem is much more up to date and has more batteries included than flask (eg FastAPI has authentication included).
Well no. None of these thing are appealing to me. As much as I hate the modern web, admin panels and forms generated server side are dead. Testing has never been an issue. As for security practices, this statement is as subjective as they come.
I am by no means a fan of flask. However it gives you a lot more freedom to structure your application to your taste. Django is basically a php 5.4 framework with a python syntax.
In this day and age fastAPI is a solid choice, so is falcon and probably half a dozen others.
If you like Flask (I do too), you can do what we used to do before Flask existed (./djngo.com -p project runserver) where .python/project.py in the zip is:
import os
from django.conf import settings
from django.core import management
from django.conf.urls import url
from django.http import HttpResponse
# Django 2.2 Release Notes
# https://docs.djangoproject.com/en/4.1/releases/2.2/
# Documentation
# https://docs.djangoproject.com/en/2.2/
__version__ = 0.1
DEBUG = True
ROOT_URLCONF = 'project'
DATABASES = {'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'project.db' }}
SECRET_KEY = os.getenv('SECRET_KEY', 'Please set a SECRET_KEY as an env var.')
if not settings.configured:
settings.configure(**locals())
def index(request):
return HttpResponse('Hello Django!')
urlpatterns = [
url(r'^$', index),
]
if __name__ == '__main__': # pragma: no cover
management.execute_from_command_line()
I find https://django-ninja.rest-framework.com/ even more awesome these days because it natively integrates with Django ORM, which I prefer over alternatives such as SQLAlchemy.
I would suggest Masonite [0]. It’s lightweight enough to replace Flask and has a plethora of built in features if you need to build a “production-ready” app. It tends to imitate Laravel in its project setup and naming conventions which, depending on your preference, can either be a boon or a bane.
I've now been writing django at work for five years and still have yet to come across a query builder/orm which is as powerful yet simple in addition to being a breeze to on-board new engineers with.
When there are queries that require the use of non-django builtins, it's also relatively easy to use django raw sql or just straight up use the psycopg2 sql.SQL dynamic string composition helpers.
With the complexity of some our chained django QueryMethods, the company would have quite literally been impossible to build without django's query builder, at the very least.