There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But...
Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it.
Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great.
Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it.
Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.
agreed, I'm more convinced now that django is really enough and get shit done even if there a poor support of async, more convinced after reading this blog post that async python is not faster (was on hn) : https://calpaterson.com/async-python-is-not-faster.html
It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0].
Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
Interesting, those results are the opposite of the techempower frameworks, which find that the async frameworks are always faster: https://www.techempower.com/benchmarks/#section=data-r20&hw=.... Though in general I'm not sure about the value of bringing async to Django. If you want more performance, you can already either throw more machines at it, or isolate some part in a service that can be written with FastAPI/Go/something. Async in general makes the code more complex and harder to write, which seems to be the opposite of what Django is for.
For an alternative to async, with better support (granted the use cases aren't exactly the same), you can hand off some processing to Celery and then get the result to the user via Channels.
It's also quite easy to swap out the templating engine for whatever front end framework that you'd like to use. Django provides tons of value even when used solely as an API server and ORM.
Agreed. Although I usually hate marketing taglines, I think Django quite realizes its tagline of "The web framework for perfectionists with deadlines."
I love Django and have been using it for many many years. Lately, however, I’ve been finding it increasingly difficult not to be annoyed by some aspects of the developer experience. For example I’d choose React + Typescript over Django templates any time of the day.
You shouldn't be downvoted for saying this. As a server-side developer of 20 years the server-side templating languages have a lot to learn from the frontend experience. And I say this as a user of Smarty, Jinja2 and now Twig & nunjucks. Template inheritance is fantastic. But...
Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into components (which Twig certainly doesn't support cleanly), building a tool to render them and then maintaining your own component library. So normally we end up with HTML bits in Storybook which are copied and pasted into Twig templates, placeholders added and then you can guess they get out of sync.
I appreciate the argument that I should "use JS server-side and render ${js_fe_framework_of_choice} server-side" and it's valid. But I'd also like to be able to run components in _any language_ and get the same DX. Note none of this is talking about hydration - I'm wanting to leverage the JS FE frameworks as clever templating engines which output dumb HTML.
I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a developer performance benefit of allowing something else to run on top and make a more composable experience.
> For example I’d choose React + Typescript over Django templates any time of the day.
What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).
Not a Django person, but I've used a few server-side templating languages, and I agree. I'd love to go mostly/entirely server-side, cut down on boilerplate AJAX calls, and ship smaller/less JS-heavy sites to the browser. But I'd also like to write my view logic in a full language, with typechecking and a solid developer experience. I'm hopeful React Server Components will help with at least some of this.
I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?
Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.
If anyone's looking something close to FastAPI but for Django, checkout django-ninja [1][2]. I recently joined a team that uses it, and it's pretty nice so far.
Great to see this project moving forward with new features and support for other backends etc. Every now and then I try out other frameworks but come back to Django for many of my projects.
Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down...
This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.
One thing I've never been able to figure out with Django is how to properly handle javascript. How do you all handle stuff like js dependencies? What I do now is just copy and paste a dependency like mapboxjs and keep it in the static folder. Would be great if I could use node or something like that and then have a way to import js dependencies in django templates. I've been using htmx and alpine js to sprinkle some js into my templates, but maintaining all of those js files always feel so clunky
Select yes when asked if you want "custom_bootstrap_compilation"
That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages.
https://cookiecutter-django.readthedocs.io/en/latest/develop...
Thanks for the tip! Just checked it out. I'm going to give it a go with an existing project. I guess for deploying I nees my build pipeline to have access to node/npm so it can build the right static files right? But I should not need npm in production.
You can use npm or similar to download and install packages, then link them in your template. Just need to get them into the right folder or perhaps link them.
- django.core.cache.backends.redis.RedisCache cache backend provides built-in support for caching with Redis
- The runserver management command now supports the --skip-checks option.
- The shell command now respects sys.__interactivehook__ at startup. This allows loading shell history between interactive sessions. As a consequence, readline is no longer loaded if running in isolated mode.
- New QuerySet.contains(obj) method returns whether the queryset contains the given object. This tries to perform the query in the simplest and fastest way possible.
- Lookup expressions may now be used in QuerySet annotations, aggregations, and directly in filters.
Readit News
Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it.
Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great.
Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it.
Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.
Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
[0]https://news.ycombinator.com/item?id=29128107
Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into components (which Twig certainly doesn't support cleanly), building a tool to render them and then maintaining your own component library. So normally we end up with HTML bits in Storybook which are copied and pasted into Twig templates, placeholders added and then you can guess they get out of sync.
I appreciate the argument that I should "use JS server-side and render ${js_fe_framework_of_choice} server-side" and it's valid. But I'd also like to be able to run components in _any language_ and get the same DX. Note none of this is talking about hydration - I'm wanting to leverage the JS FE frameworks as clever templating engines which output dumb HTML.
Or is this barking up the wrong tree entirely?
What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
Django is great. Just don't use its templates or form systems. Indeed react is a great replacement for both.
[1] https://django-ninja.rest-framework.com/
[2] https://github.com/vitalik/django-ninja
FastAPI doesn't have those issues at all...
https://rachelbythebay.com/w/2020/03/07/costly/
Select yes when asked if you want "custom_bootstrap_compilation"
That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages. https://cookiecutter-django.readthedocs.io/en/latest/develop...
- django.core.cache.backends.redis.RedisCache cache backend provides built-in support for caching with Redis
- The runserver management command now supports the --skip-checks option.
- The shell command now respects sys.__interactivehook__ at startup. This allows loading shell history between interactive sessions. As a consequence, readline is no longer loaded if running in isolated mode.
- New QuerySet.contains(obj) method returns whether the queryset contains the given object. This tries to perform the query in the simplest and fastest way possible.
- Lookup expressions may now be used in QuerySet annotations, aggregations, and directly in filters.