Hacker News new | past | comments | ask | show | jobs | submit login
The Decline of Django (david-dahan.com)
115 points by jverrecchia 51 days ago | hide | past | favorite | 162 comments



> Django looks like the 40 years old guy who feels "in" using Facebook, while everyone else is already using Instagram or TikTok.

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 also found the comparison of web frameworks being cool or trendy like social media apps to be bizarre / nonsensical.

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.


I need to write a blog post "in defence of boring, reliable tech". It baffles me that significant portions of the web crowd seem not to have learned this lesson yet. Who enjoys learning a new framework every 6 months?

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.


Especially since a 40 year old on Facebook today will have been using it since he was 26, or possibly 24 if he was at college at the time. So he’s going to be well aware that Facebook isn’t a new hip thing. (Although he might have seen the damage that Facebook did to his mental health over the years and wisely decided not to sign up for Instagram and Tiktok when they came along, so that part is not so unrealistic)


This hit home for me. I'm not yet 40, but I'm not too far off. I was using Facebook in college back in 2005. My usage had been tapering off for a couple of years, and I I permanently closed my account about around late 2015. I haven't signed up for any social network/platform since, except for Instagram that I use solely to post photos from my budding photography hobby. I only post photos in which there are either no people at all, or no recognizable faces. I only "like" photos that fit the same criteria, and I only follow people who I know very well in the real world. If I see a photo of a birthday, wedding, etc.. that I would like to "like" ~ I don't like it on Instagram; I pick up the phone and text/call/reconnect.


Which is how those of us (few) holdouts still posting on LiveJournal feel, we know its not the in thing anymore, but we prefer it because of the advantages that it has.


To continue this metaphor: If I was hiring a skipper to sail my family over the Atlantic, I would absolutely hire the "lame" 40 year old and not the hip 20 year old


I don't necessarily disagree with you (I generally prefer tried and true), but to turn that metaphor around, there were (probably) many advancements in sailing since the olden days in the field navigation, communication and weather forecast, etc, so a younger or more up-to-date sailboat might have a better time predicting and dodging storms, or even shortening the journey. And any decent skipper would be taking advantage of technologies, even though he/she _could_ navigate with a compass and sextant if needed.


> even though he/she _could_ navigate with a compass and sextant if needed.

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.


Not to mention, it's genuinely kind of sad that the author's idea of being part of the "in crowd" consists of which social network a person is using. I don't think many 40 year olds are under the illusion that they're part of the "in crowd" because they stay in touch with their grandmother on Facebook.

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.


wow... yeah... strongly strongly agree. I love email, rss, irc, etc and still use them today and strongly disagree that we shouldn't educate people coming up about these tools.


NestJS exists. I use it in production and it’s fantastic. https://nestjs.com/


TypeORM is not fantastic.

https://redd.it/lwje83

What other frameworks have you used professionally?


We don’t use TypeORM. We made our own Mongo repository library.


Wow you seem quite sensitive. It's an analogy from the author's perspective, you don't have to take it personally just because it happens to clash with your own perspective.


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.

[1] https://docs.djangoproject.com/en/3.2/ref/contrib/admin/


"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


> Bad Official Admin GUI UX

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.


Yes, and it's responsive. I am so happy as a solo founder. I can get my admin with almost no effort at all


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.

1 - https://docs.djangoproject.com/en/3.2/howto/overriding-templ...

2 - https://stackoverflow.com/questions/7860612/django-admin-mak...


There are entire companies whose business model is to give you an admin panel. You get that for free with Django.


Every time someone declares Wordpress dead 10 more sites launch using it.

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".


> Every time someone declares Wordpress dead 10 more sites launch using it.

I'm sure you're off by several orders of magnitude.


> in my opinion I have yet to see any project have better documentation than Django

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.


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.


I think that depends where in the world you are.


I've used Symfony for years, and Django for 2 years full-time, and I have to say that I find the Symfony documentation is much easier to learn from.


I use a lot of Laravel but symfony is awesome and its documentation is one of the best I have seen.


Django fan here, but honest question: is there a Flask admin at least as good as Django admin?


I'd say flask-admin is decent, but I don't think its as good as Django Admin.

https://flask-admin.readthedocs.io/en/latest/


Likely not. The Django admin is very much tied to its ORM. That's what makes it so easy to get working.


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.


1) Documentation is too verbose

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.


“ 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.


> Second, you're wrong.

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.


Did you check your desk? Get a second pair of eyes, it's always in front of you and you don't realize it.

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?!".


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?


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.


Are you talking about an API reference? Django has that: https://docs.djangoproject.com/en/3.2/ref/

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.


> What??? 4 and 5 are legit complaints, the rest is literally the nittiest of picks, in my opinion.

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.


> 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.


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).


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


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.

[0] https://www.django-rest-framework.org/


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 like Unpoly[1] a lot. Seems like the perfect companion for django template based projects. It's like htmx but with more features.

https://unpoly.com/


Second the recommendation for htmx. It is awesome.


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 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.


What do you mean by "real"?


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 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.


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.


You may want to keep an eye on https://github.com/vitalik/django-ninja

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?


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 :)


> If you're a 22 years old student, you probably never used and will never use IRC.

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!


"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.


This article is a cry for attention, at best. I suppose yet another dev bought into the "you should start blogging to become a thought leader". However, it reveals character traits that won't be helping the author: shitty writing, ageism, negativity, and blaming.

Seriously author, you did not help yourself.


He's "CTO as a service"

Imagine turning up to a job and this guy is in charge of decisions...shudder.


> CTO as a service

Jesus Christ.


This post radiates an idea that Django is a dying framework. I cannot emphasise how wrong the entire premise is.

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 :(


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.”


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


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".


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.

1. https://www.mattlayman.com/blog/2021/how-to-htmx-django/


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.


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.


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.


I think the comparison between VS Code and Chrome is spot on. Monoculture in the text editor/IDE space is a very real risk right now.


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..

[0] more context: https://stackoverflow.com/questions/27475432/pycharm-docstri...


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.


This is true.


Never used anything but Django REST Framework as far as Django goes. Couldn't be happier. Love the ORM.

https://www.django-rest-framework.org/

(I have other controversial opinions like GraphQL is the new XML SOAP)


> (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


This guy sounds like a textbook example of CV driven developer.

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.


Every couple of a years Y Combinator CTOs do a survey of their MVP. Every single time Django on Heroku wins. If it's on the decline, I doubt it has fallen out of first place yet


I mean, web development is kinda like that 40 year guy who feels "in" using Facebook. As an industry it's 25 years old and approaching maturity. The author cites Node and TypeScript as where the cool kids are, but that was where the cool kids were 8 years ago.

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.


The cool kids today are into cryptocurrencies, AI, and robotics

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.


Still there, just different frameworks. Think of AI 2012 = Web 1995, TensorFlow = Netscape, PyTorch = IE, and Jax = Firefox. We're at about 2004 and Chrome hasn't been invented yet. There's probably another "pole" of the ecosystem (analogous to server frameworks like Rails & Django) that also hasn't been invented yet.

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.


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.


Django, Python and htmx.org are great. Neither old nor boring. It works. The docs are great. It works on raspberry up to huge cloud setups. Have fun


> But what if tomorrow, Microsoft launches a full-featured node/Typescript framework? You would get:

> 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


I don't understand why a Python programmer would move from PyCharm to VS Code. PyCharm is pretty perfect as far as I can tell. I've tried to move to VS Code a few times to keep up with the cool kids, but I always seem to run into weird problems.


I agree. VS Code is a perfectly nice general purpose IDE but for Python work there’s really no comparison to PyCharm.


An article of unsubstantiated nonsense with a flamebait title.


Some of the author's complaints are legit, but they hardly constitute evidence of decline.

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.


As a Drupal developer, I understand what this article is saying. The issue is that these systems are built for an older paradigm and not meeting the needs of today's developers. It's taking time to adjust existing code to the new ways, and the developer crowd that built them is interested in new things.

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.


I've done both Drupal and Django work in my career.

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.


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.


I think the only real option here would be DRF, it's a very mature library to switch Django from website builder to API backend


Agreed, Django + DRF provides everything you need for this use case out of the box.


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.


That would be django-rest-framework.


I've recently started using Django Ninja at work, and I really like the FastAPI-like request/response schema handling.

[1] https://django-ninja.rest-framework.com/


what's the point of this post? what a neghead.


"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?


I don’t buy in “the dealing with two IDEs is not an option”, many people use many IDEs depending on what they do. I find myself jumping between PyCharm, VSCode and Visual Studio all the time at work. At home, I will have PyCharm running permanently as the core programming environment for the colour-science projects and VSCode also in the background for everything else.


Looks like the typical naive person that would critique the admin UI, the ORM, the documentation, the template system, etc and would then opt for doing his own thing in pure python and just flask and this other library and end up with a terribly worse implementation of everything he was complaining about.

I've seen this with my own eyes in the past.


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.


Django is (or was) one of the "famous" Python frameworks (there was a time when most Python jobs where Django jobs, or the "gateway" to Python was via Django).

Yet I also thought it broke a few Python conventions, being fairly tightly coupled..


Django has never been more popular.

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.


some decline:

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.


Not sure I'd call Rails an independently wealthy person's 'passion project'. He's wealthy because of his startup, which Rails came from. Rails development happens because Basecamp makes things with it...


I wonder how seriously this kind of graph should be taken. IMHO, it surely correlates with the number of newcomers, but also, with how newcomer-friendly a topic is.


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.


I just want to point out the typo in the heading for the critique about bad documentation:

> Oudtated Documentation


I wish there was still a "for me to poop on" app so I could poop on this.

-40 year old guy


Don't waste your time reading this.


Eh a lot of these seems like strengths of Django. Rails chasing the SPA dragon has been a source of endless pain.


Could you elaborate? After a ~10 years hiatus I revisited Rails last year and whipped up a CRUD app with auth in no time. No SPA in sight.


This was always Rails' strength from day one. The problems came when you tried to do anything that didn't fit into the guardrails laid down by RoR.


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 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.


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.


What’s better?


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.


Keystone.js has an admin similar to Django, but nowhere near as full featured.


Rails.

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 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.


I swear I saw an article on here a few months ago about the decline of Rails


Someone needs to coin the term "mansion-shedding": Bikeshedding, but it's about the choice between two or more proven, reliable, working solutions.


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 love the fact that rails also provides a solution/opinion to the frontend part. Django sounds like nowadays can only be used for backend.


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.

https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2... https://www.tiobe.com/tiobe-index/ https://spectrum.ieee.org/top-programming-languages/


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.


Zope & Plone! ;)

https://zope.org/

https://plone.org/

...if bigger = better...


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! ;-)


Plone is second last in my "list of platforms I enjoyed writing code for when working at a wanky web agency".

Number one is OpenCMS.


Just using Django as an ORM and not a templeting library


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.

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


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.


Flask? Maybe FastAPI.


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.


Pydantic's BaseSettings has cured my configuration-DSL itch. You can type in (typed) defaults in Python and have them overidden by env vars.


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.


Would go FastAPI for new projects.

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).


We've been enjoying FastAPI, but we very much fall into the "we just want to expose this thing as an API / endpoint for jinja2 templates" camp.


Does Go fit here?


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).


The worst part of Django is ORM. Unfortunately, this is the main part, too.


That was true maybe 8 years ago, but it is definitely top tier now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: