I don't know Phoenix enough to make a fair comparison, but I'd say it have major features Django doesn't have (like LiveView), but the opposite is probably true.
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.
I really like the Genshi templating language, which TurboGears uses by default. Genshi is a descendent of the Kid templating language, but it uses a (debuggable) streams-based api instead of compiling templates to (undebuggable) Python code. You can use Genshi with Django, of course.
I like the templating languages that remain valid HTML. It makes it much easier to integrate with other tools like HTML formatters or HTML plugins for JavaScript bundlers.
The beauty of Genshi is that its templates are pure clean valid standard XML, so it interoperates perfectly with all XML tools, and it has independent serializers for all the dirty quirky variants of HTML. So you can render your templates in XHTML, or any other version of HTML you want, and edit and process templates with off-the-shelf XML tools, that don't need to know about any special non-standard syntax.
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.
I second FastAPI! In my mind it's, "Flask, but better." The killer feature in my mind is that it leverages type hinting and dataclasses, using Pydantic, to take away a lot of the grindyy, boilerplate parts of writing an API, like type checking, dependency injection, generating good error messages, generating API documentation, ...
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.
And Docker secrets! It's also pretty easy to rig them up with YAML files! BaseSettings is amazing.
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.
To be fair, I'm familiar with Flask and (some) of its complimentary modules. FastAPI has a lot of buzz right now, but it's also fairly new - I'll probably experiment with it first.
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.
I agree. Maybe a was bit unclear. I think the nice thing about micro frameworks like Flask is that you can build your own Django. Or your own whatever it is you need.
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).
I'd argue it's not the same thing. Bike-shedding happens over trivial, subjective things where any opinion is as valid, and hard to rebuke because of the subjectivity.
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.
There is tons of subjectivity in software development; people can't even agree when types are better than duck typing and vice versa. Even if there is some definite answer to all these questions we are not all ever going to agree on it in big numbers, so yes I think language framework wars can be called bikeshedding in most cases. Especially considering comparing Rails and Django is comparing two very very robust, "old" and proven solutions with about equal performance and feature set. Even the syntax is pretty similar. If one is objectively "better" it's not gonna be by much. It's not gonna matter at all to your average project which one you choose.
I just wanted to provide an alternate viewpoint; I also switched from Django to Rails, but much preferred Django. In my opinion the documentation is much better (the Rails documentation sites drive me bananas daily for both reasons of their content and UIs) and I very much appreciate the slow pace of changes to the framework.
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.
If you're trying to write an api, yes absolutely it is more suitable.
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).
Here’s my subjective suggestion and a list of things I like about it in no particular order:
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.
Phoenix/Elixir is so niche I don't know how you can put it in the same line as Django/Rails/Node. There are major consquences to picking something so niche most companies will not go along no matter how awesome the tech is.
Niche? Maybe in some areas. There are at least 10 companies using Elixir within biking distance of my house. I've been working with Elixir professionally for six years and have never had an issue getting a job or hiring people. Things may be different in your area.
Yes, niche, as in not in the top 50 in Tiobe index, as in less than 25k people on the Elixir subreddit, as in around 1000 jobs in the whole of the U.S which is a fraction of the popular stacks.
Niche. No matter which measurement I go with Elixir isn't anywhere near the top 20. The third one (spectrum) is actually a combination of 11 measurement metrics, so before you yell at me that Elixir devs don't use Stackoverflow - Elixir isn't niche only on Stackoverflow. It's just niche, period.
I don't think this question is answerable so abstractly. It really depends what you're trying to build and what the technical constraints are.
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.
You beat me to this exact reply: as "dead" frameworks go, getting real work done for real tangible value rocks, with Django, with Plone. I can't wait for the follow-up post explaining why FastAPI is dying, make tiangolo proud! ;-)
They've been mucking with the asset pipeline every single version and their forray into webpacker has been a disaster. Turbolinks and ActionCable have been attempts to compete with SPAs while still being SSR but both are just glitchy and a source of endless Heizenbugs. Thankfully Rails7 looks like they've restored sanity.
I must admit that zhe Turbolinks does glitchy stuff with the theme I ripped ( project is in the Ask-for-forgiveness stage ).
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.
I have high hopes that Rails 7 will be much saner. Importmaps are such a Railsy solution, and if you need anything more jsbundling-rails will provide easy starters for ESbuild, Rollup and Webpack.
If I were to have a Django backend and only be serving Json responses, what combination of methods/libraries are commonly used for that? Such as input validation, client side request sending, etc.
That's probably not the right use case for Django (I say this as someone who defaults to Django for new projects unless there's a compelling reason not to).
Something like FastAPI would be better suited to a narrow use case like that, as that's what it specializes in.
I would also prefer to use FastAPI [with Pydantic models] for something like this today too. That said, this is Django + DRF's bread and butter, even if the framework itself is a little dated these days.
I'm pretty happy with the Django projects I start out these days. Most of them are just GraphQL APIs that interact with a React SPA, with a nifty admin built right in. You don't necessarily need to use all of the components of Django to get a tremendous amount of value from using the framework. It used to be a very much "batteries included" framework, whereas now I'd consider a bit closer to "cafeteria Catholic". Still philosophically a far cry from "omakase".
"Not as hip as tiktok" and not modern because the page reloads when navigating? It's not suitable for an API because... no real reason given, and the myriad projects doing this left unmentioned.
I think there are a lot of good reasons to criticize Django, this blog post failed to find them.
I appreciate the article as a list of ways Django could better align with the author’s personal preferences, but nothing here is a case for Django’s “decline.”
Is instagram not hip anymore ? I’m using fastAPI after moving to flask for a personal project but all of these microfraneworks make me want Django for what is built in. Also , why not have backend frameworks in JavaScript? Everyone focuses on performance and disregards ergonomics.
> 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.
I’ve heard of another company that replaced Django’s ORM with sqlalchemy. Also, I am going to switch to Django ninja fastAPI is good but this is a backend to a video game so I’m going to need a backend and login information and you can add a CMS using wagtail which I will need so thanks for the link :)
I can't comment on every use case, but I've recently been using htmx[1] with Django templates to provide sort-of async behaviour. For me it's the best of both worlds; I can specify my template and view as though it's a normal page load, and then use some hx- attributes to make it async.
Yep. I wrote a web app a few years ago that was moderately popular in its niche, using Django and htmx's predecessor, intercooler to add interactivity. I think the big issue with this article is that the author fundamentally wants to write client-side apps, and Django is a server-side framework, so it's not really meeting his needs.
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.
"The decline of Django" -- should come with what replaces it note. Where people are fleeing from here? or which new tech is better for these requirements?
It might just be me but I really wish 95% web apps/sites didn't try to be single page apps. They have obscure failure modes, they're harder to QA, they require huge amounts of bandwidth and they're expensive to build.
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.
The only point I can sympathize with a little bit is the default admin UI looks, which could be a little more modern.
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.
Seems like a strange bit of feedback to me. My company uses Django as the backend for our REST API and it's simply phenomenal. Django isn't a complete solution out of the box, but that's why things like Django REST Framework [0] exist. It supports JSON-based views and has an excellent serialization layer that can map directly to the ORM models.
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.
The core DNA of Django has always been conventional publishing / content management. It's usable for SPA, hybrid rendering models, and so on, but I would be nervous about putting in too much to make those first class, vs just steering people to other projects or frameworks for which those types of uses are the primary target.
I think the case for server-side HTML rendering has never been stronger, and of all Django projects I work on, the ones I enjoy most are those that never got on the SPA bandwagon. From both a developer and user point of view I find them much faster and less painful. There are many cases where you really, really don't need the massive amount of extra complexity involved in designing APIs, adding JS frameworks etc.
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.
I typically use DRF + Django for the backend and then have one “view” that renders an index.html with a context bridge (passed via a global JS variable) so I can bootstrap the front end with enough server side state to load quickly (and do feature gating and whatnot).
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.
The fundamental premise of this post is that a boring web framework is bad, but making basic websites doesn't need to be an exercise in bleeding edge frustration.
Django, many years later, still presents a straightforward solution to a straightforward problem, (almost) all batteries included.
Django is good. But I’ve used laravel and .bet core a lot before trying django for my personal projects. Honestly I get what the author meant by the docs is overly documented. It’s not to the point, also it’s hard to find things.
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's my main issue with Django, and why I prefer a "bring your own modules" framework like Flask. Django is very "batteries included", but if you're not using the full Django paradigm, it gets more finicky.
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.
People basically don't know what they want. That applies to developers as well. Sometimes we want things to be built-in. Sometimes we want to bring our own modules. Can we just agree to do and choose whatever works best for us at any point of our developer's life?
Totally agreed. That's why I pointed out the difference. I've used many frameworks, and each brings it's own flavor and benefits to the table.
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.
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.
Number 1 isn’t a show stopper in any way but is it pretty annoying. The primary django docs are very textual and place more emphasis on developing intuition and understanding context, than something that can be quickly referenced. Also a lot of the method parameters are either not documented or not explained. I think Django would benefit from a more technical and complete but less dense secondary reference.
I fully agree, it usually ends up being barely useful, and not enough. It does not explain how certain parts of the magic happen, what the best practices are, what the expected types for arguments may be, etc.
It's not bad, but usually verbose in the wrong bits, and sparse in the details.
“ more technical and complete but less dense secondary reference.”
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.
A lot of devs don't understand this, but can save a lot of time, especially when the code is all python. Especially if you questions are off the beaten track
Django has one of the best source code base I ever saw, in 20+ years of doing software. If anyone has issues reading the Django source code, they probably should stay away from software development.
> If anyone has issues reading the Django source code, they probably should stay away from software development.
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.
I halfway agree. However in a multi-framework system I don’t have to time to learn the project structure of all my dependencies for quick lookup. Maybe if the Django docs linked to the underlying source code that would be a good compromise?
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.
This was my response exactly. The article is a list of nits, not major issues, and most are not about the framework itself, but rather things like tooling conveniences.
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.
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.
I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet.
> I'd recommend giving a bit more weight to the experiences of other developers. Static typing in Python has become fairly widespread and even idiomatic in some circles, even if you haven't experienced that yet.
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 took the point of the article to be that Django is making no effort to enter the now fairly idiomatic world of static type checking in Python?
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.
the one thing I actually like about django is consistency, which is exactly what i am looking for when i am deploying something to production.
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.
I don't know about #4. I use async several places in my django 2.x project without issue. I'm not entirely sure where django it self might need to be made async
I love Python, and I love Django, but I think async support would be a bad idea personally.
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).
I don't really understand this article at all. It comes across as a rant rather than picking on anything that actually points to a decline. Django is fully featured and still fast as ever. There are dozens of packages out there that extend it and the nature behind the way Django was built it encourages those packages.
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
Eh, "[insert stable, mature MVC framework] is dying/dead/etc" articles are a dime a dozen on the Web. I suppose it could be considered a badge of honor for a framework to have some internet punter declare the framework as "dead". But, just to nitpick...
> 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.
Symfony is a great project, I just feel like, in comparing it to Django, there are so few people who would choose PHP over Python that it's not really a fair fight.
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.
"Eh, "[insert stable, mature MVC framework] is dying/dead/etc" articles are a dime a dozen on the Web. I suppose it could be considered a badge of honor for a framework to have some internet punter declare the framework as "dead"."
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.
> It is now official. Netcraft has confirmed: BSD is dying One more crippling bombshell hit the already beleaguered BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers
Nothing you wrote invalidate the point he makes about admin UX. Internal pages may not need to be fancy, but realizing that expectations change over time and that it may be a good idea to polish the UX a little isn't something that should be ignored by saying that only internal people will use it.
If the claim had been about ugliness, then you may have had a point, but it was not, it was about UX.
I love Django & run it in prod. I had a really tough time figuring out how to customize the Django admin interface.
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.
Same thing with the Grails framework, which is another Rails framework for Java eco-system.
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.
Found lots of things rubbed me the wrong way about this post, though tbh I really haven't done Django dev; only Flask.
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.
Pycharm gets little love, esp comapred to the free alternative, VS code.
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..
That's par for the course with JetBrains. I'm a big fan of PyCharm, don't get me wrong. It was the first IDE I've tried out of maybe a dozen that actually gave me a reason to convert from Vim with plugins and a number of self-written project mgmt/organization tools.
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.
Frankly VS Code scares me. Just like Google Chrome, it went from nothing to being the IDE that everyone use. Just like Google Chrome it is backed by a corporation that does not have the user's best interest in mind.
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.
172 comments
[ 3.4 ms ] story [ 186 ms ] threadBut 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.
https://en.wikipedia.org/wiki/Genshi_(templating_language)
https://pythonhosted.org/Genshi/templates.html
https://genshi.readthedocs.io/en/latest/api/template/
https://pypi.org/project/django-genshi/
https://github.com/phispi/django-genshi-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).
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!
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.
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.
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).
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.
https://zope.org/
https://plone.org/
...if bigger = better...
Number one is OpenCMS.
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.
Something like FastAPI would be better suited to a narrow use case like that, as that's what it specializes in.
[1] https://django-ninja.rest-framework.com/
I think there are a lot of good reasons to criticize Django, this blog post failed to find them.
> 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?
1. https://www.mattlayman.com/blog/2021/how-to-htmx-django/
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.
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.
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
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.
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.
[0] https://www.django-rest-framework.org/
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.
https://unpoly.com/
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, many years later, still presents a straightforward solution to a straightforward problem, (almost) all batteries included.
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.
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.
It's not bad, but usually verbose in the wrong bits, and sparse in the details.
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?!".
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.
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.
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).
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
> 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/
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.
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.
https://flask-admin.readthedocs.io/en/latest/
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.
If the claim had been about ugliness, then you may have had a point, but it was not, it was about UX.
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.
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.
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.
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.
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.