The Decline of Django
david-dahan.com
david-dahan.com
wow fuck ageist bullshit like this. everyone knows I'm no big Django advocate but what is the point of a blog post like this? I'm not seeing how effort spent on writing articles like this makes the world better for anybody, including the author. Go create something?
>But what if tomorrow, Microsoft launches a full-featured node/Typescript framework? You would get ... In my opinion, a framework like this would nail it
it's all you bro, *go write it* and show everyone how right you are!
I don't want my web framework(s) to be trendy, or cool, or in — I want them to be battle-tested and "just work" regardless of implementation language.
Tools are not supposed to be exciting. We're not usually hyped for a new version of a hammer, wrench or a soldering iron. That's not the point. This collective ADHD is really counter-productive IMO.
I still remember that comment on HN a couple of years ago where somebody was claiming that JQuery was dead because there hadn't be a new release in literally 4 months.
The person with 22 years experience could fall back like this thanks to survivor bias, the person with 2 years experience might have been lucky so far.
I had to wonder what FB chose as a cultural strategy that left them down for hours when other companies can recover virtually anything in under an hour and if a focus on being less cool and less ageist would have helped them.
The ironic part about that sentiment is that the author is clearly well on their way to becoming the 40 year old they were making fun of - one who doesn't grow up and continues to rely upon social media to obtain affirmation.
What other frameworks have you used professionally?
> Bad Official Admin GUI UX
For anyone reading, Django's admin tool is designed for situations in which you need to stand up a quick admin or build some internal admin functionality. For more complex cases, you build your own admin to fit your user needs (including the UI/UX). From Django's own documentation:
> The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around. [1]
Also, regarding documentation, in my opinion I have yet to see any project have better documentation than Django.
[1] https://docs.djangoproject.com/en/3.2/ref/contrib/admin/
Well said, people confuse hype, growth with death. If something is not hyped or people some folks are switching to something else then it is prematurely declared "as dead" which is a fallacy of thinking.
As bad as it is, it enabled our team of all backend devs to stand up a functioning infrastructure management tool that was mission critical to the business's success in the early stages, for relatively low effort.
I guess it just depends on what you're using the tool for.
You need to do a lot of overrides on things [1] and changing up the model / form behaviors etc. gets a bit clunky, but at least is manageable [2].
I will say that 99% of my work is using django+drf for REST API purposes, so I wasn't previously familiar with django templating / forms, etc. - maybe that is where the bulk of the learning curve was.
1 - https://docs.djangoproject.com/en/3.2/howto/overriding-templ...
2 - https://stackoverflow.com/questions/7860612/django-admin-mak...
It's like that old saw from Strousstroup: "There are two kinds of programming languages. The ones people complain about and the ones nobody uses".
I'm sure you're off by several orders of magnitude.
I'm partial to Symfony. Good "getting started", per component documentation and links to cookbook-style articles for things people tend to want to do.
If the claim had been about ugliness, then you may have had a point, but it was not, it was about UX.
2) Onboarding new developers lacks IDE specific tooling for free
3) Admin GUI isn't great
4) Async support is still incomplete
5) Static types aren't used in Django
6) Django is MVC which isn't useful if you just need a light V
7) People ignore other, newer tech because Django exists
What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion. You don't like a framework because it's so good, people don't experiment with newer frameworks?? And that's in your article about the decline of that framework?
This is a weird article, man. I am surprised they haven't figured out async yet, and I guess if you really like static types the lack of them in Django would be annoying, but otherwise this just seems like you set a goal to write about a topic, and forced yourself to come up with an article you thought hasn't been written before. Like, it feels like you wrote the title of the article, and then tried to come up with the rest of it after the fact.
Isn’t that basically just reading the source code? Like I get that’s probably not right to throw everyone toward, but reading source code is a staple task for working with FOSS.
First of all, juniors exist you know that right? Please don't gatekeep.
Second, you're wrong. The Django codebase is overall good quality but if it's "one of the best you ever saw in 20 years" you haven't dug deep. Django has a lot of horrible no good bad awful parts to it. To their credit they tend to improve with age, not get worse, but it's certainly not worthy of such praise imo.
So you know better than me what source code I've read so far? Do you also happen to know what did I do with my spare camera battery? That could be useful.
If you're going to state opinions as facts, you can't then come back and tell people "oh so you know my own opinions better than me?!".
It's not bad, but usually verbose in the wrong bits, and sparse in the details.
They have an entire set of tutorial/getting started type docs that are definitely very wordy and based around getting you comfortable with Django's paradigm, but they do have a rather well done API/Module reference that does a good job getting to the meat of the topic imo.
I'm surprised someone finds room to criticize the Django docs. It's got the best docs of any web framework I've used in the past decade. It's great to be able to find everything you need easily in one place and not have to go searching for Stack Overflow answers or blog posts just to solve common problems.
I'd argue that 4) (async support) is the only meaningful point and 5) , given it's a Python framework, is at most a nice-to-have.
But yes, this article is a complete waste of a click.
Same thing here, and I've been writing Django code for a living for 15 years now. What baffled me was the complaint about the admin interface, if used right can get a small business up and running almost instantly.
You should really refrain from filling in the void in your understanding or knowledge of anyone else's experience with output from your imagination.
Also, I'm not sure you noticed the absurdity of trying to sell Python's type hints as being "idiomatic in some circles" when you're discussing a specific circle of Python which is renowned for not using type hints at all.
I guess we could reasonably debate about the meaning of "nice-to-have", but for some people including me, I would find working with a framework that thwarted my efforts to statically type my code to be more than just "not nice" - I would actively avoid it. Which, again, I believe gets at the heart of the article. There are plenty of folks who will choose not to use Django precisely because it seems not to be evolving alongside the language.
I’ve written a lot of things using asyncio and steered into it hard when it was first stable, but I’ve found it cumbersome and (zooming out) pretty unnecessary in the grand scheme of things.
Asyncio is cooperative concurrency where you’re supposed to politely yield back to the event loop when you’re blocking on IO, but the event loop doesn’t bawk (that I’ve seen) when things are blocking accidentally. I’ve chased a number of very real bugs around this in production and I will say it’s some of the most infuriatingly difficult to pin down set of bugs I’ve encountered to date (for example, redis is fast enough to not notice any issues until your redis query grows slow enough that you do, and at that point things behave strangely with no clear indication why).
Remember, even printing things to stdout is still technically a blocking IO operation. Same with reading/writing any files. Lots of issues can crop up in weird ways with stuff like this.
On the other hand, the “boring” Python threading library is preemptive concurrency, meaning your libraries can’t hold things up even if you wanted to. In general give me preemptive concurrency any day - I find it easier to carefully code around state mutations than diagnose why a library might be blocking the event loop. I haven’t noticed a massive perf difference between the two and to guarantee that I don’t have weird “you’re blocking accidentally” sorts of issues means I’ll stick with threads any day of the week.
Also exception handling in asyncio land is (again just from my experience, it’s been a couple years) not great, I subscribe to the mantra of letting things crash, but things silently crashing is a deep seeded behavior change that seems to go against the Python mantra of “throw exceptions and let things fail”.
For now I keep things boring with Python, and if I need massive concurrency just rewrite things in elixir (which is preemptive concurrency and the actor model which is super powerful as a combo).
Async support is nice and all, but i fell in love with django (and the eco system) mainly because it solves problems which i really don't want to concentrate on.
This setup does NOT help with serving our frontend app, but we're using React for that anyway and I'm not sure I'd want our frontend so tightly coupled to the backend.
The fact that Django is mature and extremely stable between versions is a huge selling point for us. I'm not interested in making sweeping changes to our backend just because someone invented a new paradigm that may or may not be helpful to our app (eg, GraphQL).
That said, rendering HTML templates server-side does feel pretty archaic these days. I think it would be great for Django to take a more API-centric approach for a default installation. I can imagine that anybody coming from the JS world would feel totally out of place in terms of how Django works out of the box.
When you need a bit of extra UI goodness, htmx https://htmx.org/ is a fantastic solution, and you can still use SPA-type approaches for things that need them.
You can also benefit from massively faster (and more reliable) functional testing when you are mostly standard HTML - see django-functest https://github.com/django-functest/django-functest/ for an example of this.
Seems to be a great combo to me - you get all the awesomeness of Django/DRF and none of the more archaic html temperate rendering stuff.
The only bad bit I’ve found in Django is lack of real websocket support when it’s needed. Server side events are great to have.
Django's postback model might not be a model of what front end developers want to use for their backend, but it's definitely a model of how I like my frontends to behave - sparse and minimalist with a limited number of possible behaviors.
Django, many years later, still presents a straightforward solution to a straightforward problem, (almost) all batteries included.
> I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
Its still a bit young, but I like a lot of what they are doing.
As for Instagram, I wonder if they replaced the ORM with their own in-house ORM or something else?
It seems that the author does not realize that filtering out 22 years old students may be a feature, not a bug. If you need to be convinced just look at the dev mailing list before Google summer of code, lots of low effort proposals borderline on spam. I cannot blame maintainers for trying to shield themselves from some users.
An advice from someone who was a 22 years old student not so long ago? Learn to use IRC, it's awesome!
I think there are a lot of good reasons to criticize Django, this blog post failed to find them.
Seriously author, you did not help yourself.
Imagine turning up to a job and this guy is in charge of decisions...shudder.
Jesus Christ.
I’ve used a bunch of frameworks all over the python/nodes/jvm ecosystems. But every single time I come back to Django, it’s a breath of fresh air where I don’t need to plumb common patterns for my case. It’s so mature that any use case I run into, the solution is just a google/documentation away.
If at all it’s true that Django is dying, I’d really be sad to see such a mature framework go :(
It seems that the only genuine gripe is with documentation. Okay -- so contribute those changes? I've contributed documentation to lots of packages I use, including DRF, celery and so on. It's an open source project with an awesome community behind it. If you feel that docs need updating, then update them. It doesn't mean there is a decline in any way, shape or form just because it uses IRC as a support channel[0] rather than Discord.
[0] Worth mentioning that the Django support channel is perhaps the best support channel for any similar project of this size you can find
The async issue is valid — I have wanted to use server-sent events with intercooler/htmx — but the answer seems to be just to use Django Channels, or be patient and wait until the async features are actually finished.
I'll just nitpick on their bagging on Pycharm. Pycharm is great. Frankly, I like it better than VS Code; though I do grant VS Code has its strengths, especially as a lightweight capable code editor.
Now I read an article that basically explains that Django is declining because of its poor support in VS Code, that cannot be a good sign.
I actually like, use, and pay for PyCharm, but it annoys me when JB chase new (ds) customers with DataSpell, or teams management stuff with "Space", When long standing, trivial Pycharm bugs have gone unfixed for years; https://youtrack.jetbrains.com/issue/PY-14743 [0]. I have no hope Pycharm will innovate any time soon, and will eventually fall behind more motivated IDEs.
Also, the whole "IDE specific to one language/domain" thing is a little Janky when, IDEA with plugins vs the "specialised" IDEs can differ so much. I feel JB are trying to build a single code base to spawn multiple, separately marketed, product more than any advantage to end-users. For a while I had to keep switching from PyCharm to IDEA just for Jenkinsfile support..
[0] more context: https://stackoverflow.com/questions/27475432/pycharm-docstri...
That said, JetBrains often rolls out new things while sitting on long-standing bugs. There's three or four issues in PyCharm and TeamCity that I've been tracking for a couple of years that are older than my kids. Hell, I think one of the TeamCity issues is almost old enough to get a learner's permit.
https://www.django-rest-framework.org/
(I have other controversial opinions like GraphQL is the new XML SOAP)
Wow, that is a funny observation haha, hope to see a post expounding on that idea on HN someday
I've delivered large amount of value to business with boring technologies like Java, Django and made good money in the process. Sometimes all the client needs is a simple CRUD app. Coincidentally, I turned 40 this year.
The cool kids today are into cryptocurrencies, AI, and robotics. Even there, some of the frameworks you probably think of bleeding edge are already losing mindshare. TensorFlow is giving way to JAX, Bitcoin already gave way to Ethereum which is itself getting eclipsed by Algorand, Cardano, and Solana.
That too is where the cool kids were 8 years ago... Even I was into all that 8 years ago and I was never a "cool kid". I have no idea what the cool kids are into these days. AI is still hot though, so perhaps they are building GPT-4.
Or in the crypto world, Bitcoin 2009 = WWW 1989. Ethereum 2015 = Netscape 1995. Facebook Libra/Diem 2019 = IE5 1999, except less successful. Actually useful cryptocurrencies haven't been invented yet, although they probably exist in nascent form. Think of how the web came to be primarily used for social media, communications, discussions, information - all of which existed in the form of Fark, SomethingAwful, Xanga, etc. in 1999, but MySpace, Facebook, LinkedIn, Reddit, YouTube, Yelp, AirBnB etc. were all in the far-off future.
In any case, I don't know of any one other framework with a remotely comparable admin interface in terms of capabilities and usability out of the box, so there's that. I'd be happy to be proven wrong.
For everything else (even async with channels), as long as you don't stray too much from the django way, you'll be immensely rewarded by how neat and easy to navigate even large applications look.
> all modern features and tooling Django has failed to provide over the last years
> having to master only one language as a developer.
> safety of a big corp to maintain the framework, rather than relying on individuals
Yeah that's called ASP.NET
First, I figured out how to do Django+Tornado in a day 8 years ago and PyCharm pays for itself over and over, every day.
The rest of the arguments might deserve mention in a conversation about how the project could be improved, but it isn't clear to me that they presage Django following Visual Basic down the drain.
I'm sure the Django maintainers would entertain PRs for any clear improvements over what's in place and lacking.
Some projects need the rapid development capability of a CMS, but want the front end flexibility of a js app.
The problem is that the plumbing produced by these systems are geared to serve whole pages, and not an API first app. We've added the ability to layer an app on top of the CMS, but most of the content and admin pages don't fully use ajax (at least in drupal).
The reason for the current problem is that these open source frameworks required a ton of contribution to become successful. That effort has moved on to new projects with fresh architecture. But those still don't have nearly the same level of features as traditional platforms.
One of the challenges I see for building the perfect system is having all the front end features and components integrated. In Drupal, a module may add a component with template and some css/js. Other modules are free modify or mix this component with others, so the data model, styles, and js all need to be compatible. Drupal solves this by standardizing on jquery, which was a wonderful solution for the last decade but now people don't want to use it.
I think to get the same level of compatibility in a js app, you would have to define the components to be included by the system. These are the batteries they currently don't include. It's less of a technology issue and more of a challenge of defining standard ways of doing things that are not overly opinionated.
I would love to have an easy point and click CMS that lets me quickly assemble 80% and a streamlined development experience for the rest. I can imagine something integrated with the cloud and IDE that is super quick and cheap to spin up a complex application.
Sorry if I'm just complaining about drupal in a django thread. I think the issue for both is whether we can get where we want from here or if recreating the ideas in a new language will get more traction. Or if these platforms are good enough, they'll continue to have a place in the back end, allowing users to manage content and data for custom apps.
You are right they were both invented for the full html page generation on every request paradigm.
Django's concepts are much simpler though. Building a headless, API only, back-end feels very natural. You just skip the html templates. You don't even need special libs like Django rest framework.
Drupal was invented imho, to solve a much different problem set: the community-built CMS. This is where there are many different class of users going from anonymous to full admins that can perform wide range of write actions. It probably excels in this niche. Django can do it, but using custom code/calls where you'll implement most of the logic. Drupal exposes configurations that you can tweak (and have to manage).
You hint on the combinating nature of Drupal modules where every thing can override anything. That is, for me, largely the reason I stopped using Drupal. The Drupal best-practices back in the days (6-7-8), led to awfully unmaintainable code bases for anything remotely complex.
Something like FastAPI would be better suited to a narrow use case like that, as that's what it specializes in.
Aside from all the sweet things you get with django, creating an api only project feels very “hacky” for me with an extra package to install (DRF)
That said, Django with DRF to float an API-only project/backend is almost standard at this point, and a great option if the devs are already familiar with Django. They can leverage the existing experience and get right to work without needing to get up to speed with a new framework.
In regards to the documentation, the module index can help a bit. If you know the module space you need to be in (i.e. you need to do something with the DB), just jumping into the module index and looking for entries in relation to django.db can get you in the ballpark real quick.
I wasn't disparaging Django, just commenting on my issue with it. I still used it for 2yrs, but the batteries included nature of it is something that most of my projects don't call for. When I was primarily working on web apps, I made heavy use of Flask for back-ends and APIs, with various flavors of JS for front-ends.
In one role however, we had an entire CMS/CRM/Subscription engine written in Django, and it was rather solid. Since everything was in Django, it all worked together well. When I started working with this app, it was in poor shape (and a couple versions out of date) but when we brought it up to date it was real nice. We could make good use of Django signals for all sorts of things with little extra effort, and the variety of plugins available was just fantastic.
I think the biggest skill a dev can develop is learning to recognize the pros and cons of a framework or language or tool without developing too much of a prejudice for any given one. Recognize that they are all just tools, and some are better suited for some tasks then others. Doesn't mean you can't press one into service if it's a poor fit, just means you'll need to do extra work.
Python might be a poorer fit for a highly parallel real-time task compared to something like Rust or Go. Doesn't mean you couldn't use it, but using a better option would make things easier. If you want something with an ORM, template engine, signaling system, and caching layer all built in with minimal fussing about with other libraries, Django is perfect. If you JUST want a rest api, perhaps FastAPI or Flask might be a better choice.
I've seen this with my own eyes in the past.
Yet I also thought it broke a few Python conventions, being fairly tightly coupled..
https://insights.stackoverflow.com/trends?tags=django
Would django benefit from a marketing refresh? Of course. Unfortunately, unlike rails, it isn't a passion project for an independently wealthy person.
At the risk of self-promotion, htmx is making all of these excellent, mature server side frameworks relevant again. They are very good at producing hypermedia and, if you don't try to turn them into dumb JSON data terminals, they can be extremely productive and produce wonderful applications.
After Grails got refactored between 2.x and 3.x which broke all plugins, most new Java projects went with Spring Boot. Popularity of the Grails framework has declined a lot since the release of Grails 3.0. But the strong decline the last few years I mostly blame on all MVC framework not being interesting enough for new young developers. Only David Heinemeier Hanson has a loud strong voice telling the world about how fantastic the Rails and MVC web application really are. Which makes sense considering that I feel Rails is still super popular.
But my preference is not Ruby, but rather Java :-) and I feel Grails is still awesome. And I also use Spring Boot for some projects.
The problem is the group of people who think it is only a back-end for react.
Htmx and alpinejs are trying to debunk that stereotype.
> Oudtated Documentation
-40 year old guy
But you don't need to use Actioncable at all. But I do use it, to have my C/C++ clients communicate with the SaaS. Haven't experienced anything flaky there yet and I am glad a Websocket option was included.
But as soon as you go to the JS world, you won't find any full-featured framework like Django or Rails. The Django's philosophy is that all components are built by Django team itself whereas in the JS world, existing frameworks tend to gather independent components and define conventions to make them work together in an elegant way, which is very different.
Switched from Django two years ago and never looked back. Having worked with both, Rails is more polished and pleasant to work with.
Side note: if you're building a business and already know Python/Django, stick with them!
I’m not disagreeing with you at all (as you’re expressing your valid opinion!) but wanted to leave a note to say Django is still great and still preferred for many of us. I also agree with you that it’s probably not worth switching if you’re already on one framework or the other; they both have their strengths and good communities.
When it comes to arguing over large projects, the difficulty to rebuke comes not from subjectivity, or trivial-ism, but from the project being so complex there are few with the context/experience who can properly compare the two.
As someone who has used Django, Rails, and Node, I’d recommend Elixir and Phoenix. Elixir has excellent tooling and dependency management, is functional and therefore easier to write concurrent applications with, it stores threads in private memory and uses the actor model for interprocess communications, and since it is truly concurrent, it is much more scalable than the other options I just mentioned.
Phoenix is a flexible, clean, and easy to use framework with very little, if any, magic. LiveView lets you create things like SPAs, without the use of a front-end JS framework, using standard message passing. Phoenix is also scalable as hell.
One of my favorite things about Elixir and Phoenix is the ability to handle issues in a very atomic way. If you compare an Elixir cluster with a Kubernetes cluster, Elixir is able to handle an issue with tweezers where Kubernetes would handle the same issue with a bulldozer.
https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2... https://www.tiobe.com/tiobe-index/ https://spectrum.ieee.org/top-programming-languages/
There are so many architectures, API approaches, frameworks, and languages these days. Almost any one could be argued as being better or worse off of different criteria.
Also Django being batteries included makes most comparisons very apples to oranges. Even comparing a basic CRUD web app / API in Django + DRF to Flask means pulling in like a dozen packages to help vs just the one with Django.
In the world of Python web frameworks specifically, FastAPI is really nice these days for a lot of REST API type use cases.
Number one is OpenCMS.
https://en.wikipedia.org/wiki/Genshi_(templating_language)
https://pythonhosted.org/Genshi/templates.html
https://genshi.readthedocs.io/en/latest/api/template/
Templating languages that use almost-but-not-quite-entirely-unlike-XML or -HTML don't work well with standard XML and HTML tools, because they don't recognize XML-or-HTML-with-some-magic-non-standard-syntax-sombody-nailed-on-to-the-side.
Even when I'm not using FastAPI now, I use Pydantic everywhere. Types in Python, while not nearly as useful as in a strongly typed language, are a dream come true.
The only gripe I have with Pydantic is that sometimes it has really opinionated type coercion that can get you in trouble sometimes. For instance, `Union[int, float]` will accept either an int or a float, sure, but it will always output an int. This isn't difficult to fix but may only realize it after having shot yourself in the foot.
Either is good if what you are building is something small and very focused or if you already know exactly what you want to build and want to have freedom making decisions about most aspects of the application.
But if you don't know yet what the product will be, a battery included framework like Django is very nice to get out the door quickly without having to worry too much how to structure the code, what library to use for x, etc.
Also, I think that Django is a good choice over Flask if you've never done anything in flask. But if you have an existing Flask site that can serve as a skeleton, I think it's just as good as Django as a starting point; details such as code structure and common library choice is then already handles - in fact just following https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial... will get you a lot of this too; Do you have any other batteries in mind? Ialso see Django having plenty "gotchas" (although it maybe have changed since I last used it). I definitely much prefer SQLAlchemy over DjangoORM.
But you need to spent at least once quite significant time following mega-tutorials, thinking about how to structure your application, what libraries to use for x, how to integrate them etc.
If you do that, it's great. But what I have seen in practice in various large flask app developed over years is, that in the very beginning people just jump in hacking away because it is so simple, just an app.py and a requirements.txt. Then over time they slap on the same thing Django has, but in a much less robust, hard to maintainable way. I'm guilty of the same, often simply not having time due to reality to really think things trough (the mega tutorial and similar didn't exist when I last started a Flask app).
If you're trying to write a CRUD app with a lot of admin screens, no, unless you're happy to roll your own auth, admin screens, mailer etc. (I use Go for building web apps like this and am very happy with it, but it's definitely more work thank something like Django or Rails).