This partially matches my experience.

I see Django mostly being used for prototypes, which then become "the monolith" that allows the company to grow to the point where smaller services - or dare I say "microservices" - are more appropriate. There are a couple of things that stand out to me about that use case, though.

First, Django allowed the company to build a product and grow its business to this point in the first place. Without Django, it would take significantly longer to build things. Early stage startups are all about implementation speed; they often end up building several iterations before finding traction. Django's "batteries included" approach means you end up with experienced developers who can very quickly build out a green field services with it. You also get a hiring pool of people who are able to come into a project and be productive very quickly, since the architecture is well-defined and shared by projects they've worked on in the past.

Second... monoliths rarely die. I've been doing this for almost twenty years now. I've been through multiple rewrites and initiatives to break up an existing monolith. They very rarely succeed. My recommended (and by far, my preference) approach is to impose an informal "new feature freeze" on the monolith, build out new functionality as new services using the most appropriate tool for each, and slowly shrink the monolith. Over time, as core features are maintained, they can be more cleanly separated conceptually from the rest of the monolith. Eventually you'll get to a point where it makes sense to split off some existing features into their own services... but you'll likely never get to the point where the monolith is actually gone. Once the tech debt is reduced to the point where reducing it further is no longer the most impactful thing you can be doing, it doesn't make sense to "finish". The result is that even very mature companies that were once startups end up still needing people to work on Django projects.

> It's third party ecosystem is basically dying (especially noticeable when compared to ruby on rails).

Is it?

Sure, there are fewer shiny new projects these days. If you only look at tech news, you might see fewer Django extensions and such being announced - but that doesn't mean the ecosystem is dying. It means that the ecosystem isn't rapidly growing. In this case, I'd argue that's because both Django itself and the ecosystem surrounding it are mature. There aren't a bunch of exciting new packages being released because the packages that we already have are working well enough that there isn't a need for more.

> Job hiring for Django is disappearing from the non startup arena, which is especially bad for career developers since you need a career pathway.

I'm ~40. I've been a professional developer for twenty years, and have worked for startups exclusively for ten years. I feel absolutely no need to "settle in" and specialize in a single framework. Or even a single language. While most of my experience is in Python, I've built (work) projects in Clojure/Clojurescript.

I've taken jobs where I'd never even encountered the stack they were using. I recall one interview in ~2018 where the job was leading a team refactoring a Scala monolith into microservices. The first of those were in were in Scala as well, but they were having trouble hiring. Very few candidates had Scala experience, and not many more were both capable of learning it quickly and interested in doing so. I literally searched for Scala examples in my Zoom interview, while sharing my screen. After skimming the Wikipedia page I confidently told them it wouldn't be a problem. They seemed shocked at that, and the rest of the interview was my collaborating with them on a minor ticket they were currently working on - I was able to show that I could read Scala (even though I'd never encountered it before), ask good questions, and came to the same conclusion they did on how the change should be implemented.

A couple of months after joining that company, I saw that the mobile side of the engineering team was slightly overstaffed while the backend team was understaffed. The mobile team were using Kotlin for the Android app; I suggested that we write the next service in Kotlin and pull in a couple of volunteers from the mobile team to help. It went great.

My point is that a "career pathway" means different things to different people. In a large company, specialization is valid and often a great path forward. If you want to work at smaller companies, it's really not. The frameworks that you've used, the languages that you've worked in, even the industry that you know - all of them have a much lower bar to being replaced that you'd ever think if most of your professional life has been spent in "corporate" jobs.