I think that explains some of the value for this project a bit better

sort of a tangent, but quarkus also has a concept of "dev services" that are monitorable via the dev UI. It uses Testcontainers to start and autowire runtime deps (postgres, redis, keycloak, etc.). Pretty pleasant experience to get the whole stack spun up and observable alongside the dev server.

The Django admin is really great. I do wish there could be a bit more extensibility hook points to hook into existing stuff, but I know a loooot of projects that hack stuff into the admin despite that (I think in particular it's a bit futzy to have things like confirmation screens on custom actions).

I think the real power of Django comes from not only having the batteries included, but almost always having the right kind of extension points in terms of methods (or template overrides) that really give you ways to quickly insert the right kinds of customization for your project. The admin existing and working so well for so long is proof of that IMO

I believe keeping the tooling separate and enabling them on demand totally makes sense.

I like the spirit of this, and could see Django heavy shops wanting to add bits and pieces that display tooling / services they care about in Django admin.

I used to have flower at myapp.com/flower using an auth redirect in nginx to a simple view in django that made sure it was an admin user. I think if you can make that setup easier to leverage existing tools that would be nicer than rebuilding everything.

1. Build X with pure <language of choice>. Why? LLMs will have less context needed, and onboarding engineers would be easier since there’ll be less overhead and opinionated frameworks knowledge required

2. Build X using well establish frameworks. Painful in the beginning since you’ll not only need language knowledge, but framework knowledge. The upshot, is scaling and maintainability

I love that this ecosystem will heavily pressure teams to consider (2) more and more — solving the very real “AI slop” problem