I think I get why Cloudflare’s CTO is asking this question. personally started using Django for backend development, boy, that thing is robust and cool, esp…
Never listen to people in the C-suite.
I’ve been a developer for 30 years, and used django for the vast majority of the last 15 years of backend dev work. It’s familiar, comfortable and capable, and I don’t have any real major complaints. No customer has ever complained about it either.
15 years!!! your write blogs? as fellow Developer who uses django heavily, I am Interested in reading about your project.
No blogs… I just use it mainly for CRUD apps at work for internal or customer use so it’s many different projects that aren’t related.
What is that website? Is it a part of the threadiverse?
Naaaah, it’s a standalone site. Though the UI was inspired by piefed.
How does one even find it and what is the appeal?
The post is about why no one is talking about Django, not not why they’re not using it. A lot of people use it, it’s still a solid choice, but it’s probably far from the things hyped in social media.
why no one is talking about Django is just rhetorical clickbait title to start a conversation about Django. You are interpreting it literally.
Once the topic of Django is discussed, may lead into the conversation about SQLAlchemy. Then comparing the two. Then complaining about one or the other.
Doubt there will be anyone experienced in both. I can talk about SQLAlchemy, but keep my mouth shut about Django. So enjoy to hear what others have to say about Django.
Let them speak!
I use Django and there are some things that annoy me, like the fact we still need Django Rest Framework for a decent API experience, but at the same time, Django and DRF probably overuse inheritance and abstractions, to a point that every now and then I have to look up their source code to understand what’s exactly happening.
Lack of type annotations is another aspect Django really needs to catch up compared to other frameworks, and the whole dynamic nature of Django makes it difficult to have type stubs from third party packages working reliably, with lots of false negatives and false positives. So sometimes I still have runtime errors due to typing that could have been prevented in a different framework/ORM.
So I understand why some people are adopting different and more lightweight frameworks in new projects. The admin panel can be nice, but I’m not sure I’d choose Django myself to start a new project today.
Working with django the last 10 years. I mostly agree, but I think the inheritance thing results from the DRY mantra. Its efficient and prioritizes being able to easily change central things in the framework over readability. DRF is a decent standard, but the lack of further development and innovation (“considered feature complete”) is somewhat frustrating at times. For the typing thing just enable pydantic. :)
Does Django support async now? I remember that it was supposed to come with Django 4.
Does Django support async now?
Yes it does, to some extent. It’s a work in progress. https://docs.djangoproject.com/en/6.0/topics/async/
That’s the other part that’s a bit problematic. There is some async support, but ORM calls, to my knowledge, are still blocking. There has been some effort put into it, but I’m not sure they’ll manage to reimplement it. Other parts of the framework and third party middlewares are blocking too, which makes writing async Django a bit of a minefield.
There needs to be a non negligible amount of work to make sure a given request remains asynchronous across all layers today.
That’s a pity.
One of the biggest things I miss about django is its ORM. There is simply nothing better in my opinion. It allows me to think about the application I want to write, not about all the database nonsense and how to join tables, make unions, or aggregate stuff, etc. I have to reevaluate if async is that important to me or not. Every other solution without a similar ORM feels inferior.
Remember back in the day … raw SQL. All the children in unison say, “Woah”!
There is no avoiding the database part: model module, alembic migrations, static type checking, UDF, UDF rtyping, string PRAGMAs/SET|SHOW. And a beautiful config file to link them all!
Database work is very time consuming.
have to reevaluate if async is that important to me or not.
Why would be concerning yourself about that? Should have both [a]sync support throughout. Discussing this shouldn’t even be a topic it should be the norm.
There is simply nothing better in my opinion.
Possibly SQLAlchemy? But yeah, it’s pretty good, and there are ways you can bypass it and write your own SQL in the cases where it’s suboptimal.
SQLalchemy is horrible, IMO. You have to read so much of its documentation to get a grip on things. And the backwards compatible changes they made while moving to (I think) SQLAlchemy2 make it terribly difficult to tell apart the API. And type hints were an abomination to deal with when they tried adding them (it’s better now).
And don’t get me started on migrations with alembic.
I wish the Django ORM could be extracted from Django and used in other projects, but then I also just want to go back to Django.
Reply to /u/onlinepersona SQLAlchemy crocodile tears.
Really need a layer between SQLAlchemy and FastAPI (or litestar, …). Otherwise would be messing around with SQLAlchemy/alembic internals for years. SQLAlchemy is an incredible time sink without that additional layer.
Created just such a package just never got around to publishing it:
- static type checking throughout
- sync and async support throughout
- alembic support (both async and sync)
- multiple databases. One per config file!
- model built from dotted path of (sqlmodel and sqla mixins) components module
- UDF (user defined functions)
- database settings (PRAGMA, SHOW, SET, …)
- sqlite-[pysqlite|sqlcipher|aiosqlite] and postgresql-[psycopg2|asyncpg] supported
- config does not store the password
Issues:
- retire sqlite-sqlcipher PRAGMA rekey and key. Password in config unsafe
- authentication by pulling from a password manager not implemented
- strict validation of postgresql SHOW/SET keys incomplete
While your point is valid, it’s a bit much to fault Django for the deficiencies of third-party middleware.
