Why aren't Django Admin style dashboards popular in other frameworks?

I've been out of web development for about four years now, but I think Django is unusual in providing the admin dashboard for free. Most frameworks don't want to devote the resources to that when there are third-party options you can fairly easily (ha ha) bolt on to your project. Speculatively, it may be that Django comes from a time before such a wide variety of self-service solutions existed, and based on the newspaper use case they built the framework to support, they felt like it was worth the time to do it.

I think it has to do with the times. Because sl admin came up in a pre DRF time when people use Django to serve templates, the work to build it into the framework came more naturally. With lots of more modern web app frameworks mainly focusing on just being APIs for single page applications, having html templates and stuff in the core project and having contributors build this stuff in doesn’t happen as naturally.

I totally agree though- huge selling point of Django!

It’s mostly just a UI for CRUD. And most systems are more complex, requiring UIs that operate on business logic.

Rails and Phoenix also offer similar features (called scaffolds), but they are optional. I’m sure other frameworks have similar options.

Meanwhile, Django (like Python) sometimes has unconventional names and approaches to doing common things, so that makes the pair unpleasant and awkward for those of us with experience with several other tools and frameworks.

Flask has flask-admin: https://github.com/flask-admin/flask-admin

Keeping in mind I'm referring to Django years ago, as I dont know how many of these limitations have since been lifted, the Django admin was able to be successful because Django itself only allowed a narrow subset of database constructs to be modeled in the first place. You had tables with single-column primary keys only, and then you had simple one to many, many to one, many-to-many, and their "generic foreign key" thing, and IIUC that was it. This narrow band of possible database configurations made it easier to put an admin on top of (and also to generalize into DB migrations).

There are "django-admin" style tools for SQLAlchemy (or at least there were, back when people had the notion that "the Django admin" was why Django was successful), but they have a hard time being able to generalize to SQLAlchemy's capabilities for things like table inheritance, custom join conditions, composite keys, etc. Our users, when they build out their database schemas, are throwing the whole kitchen sink in there and producing a much more personalized kind of product that does not lend itself as well to a generic CRUD gui. Nor do a lot of SQLAlchemy users really want such a thing, since they will have these very particular types of models with lots of nooks and crannies that they'd prefer to code up themselves.

The SQLAlchemy approach is a lot more schema oriented whereas the Django one strikes me as intentionally narrowed for simplicity.

As soon as you need frontend auth you'll regret going with flask or fastapi. There is no equivalent in the python world for django admin

Activeadmin in rails. The reason I believe you need an extremely widespread framework that standardized everything, like rails or django.

Kinda funny how I really disliked activeadmin 10 years ago, now I have an app that's been running for like 12 years using it and it's been doing great. Also, activeadmin improved drastically, kudos to the community

I love the Rust language and tooling, but don't use it for web dev because it lacks something like Django. I build web backends in Python because of Django. Not exclusively because of admin, but that's part of it. (Other parts include built in DB auto migrations, auth, email, templates, [de]serialization, tightly-integrated ORM etc)

I can't figure out the intended workflow for using the Rust frameworks. When I ask (eg rust webdev communities) how to build a website using them, I get no responses, or comments about how Diesel is better than Django's ORM.

It seems more doable with Flask etc in Python because of the robust ecosystem of third-party addons, but it still seems like a complexity trap due to potential mutual incompatibilities between them.

The admin page in particular is excellent for debugging, changing config, quick queries etc.

The core reason is (imo) that it's simply not possible to provide a Django admin equivalent in other frameworks because they lack the functionality to do so.

The basic dependencies for the Django admin are:

- authentication

- user permissions

- forms

- the ORM, to generate forms from model definitions and forward the admin's CRUD operations to the database

No other framework comes with all of these dependencies builtin. Yes, there are individual plugins to retrofit them, but then you would start building your extremely complex admin plugin on top of a lot of unaligned dependencies. Just one of them needs to go into a direction that doesn't align with your needs and your project is done. That's not a good base to start from. Django doesn't have this problem because the entire framework is built under one roof.

Can you clarify what's the "tremendous value" you're getting out of the Django admin?

At Heii On-Call https://heiioncall.com/ we are using Active Admin https://activeadmin.info/ for Ruby on Rails, which seems quite similar to the Django admin. In my experience, it's mostly useful as a fairly basic read-only view of what's in the database. In Rails, it's so easy to whip together a custom view that we tend to do that, and the Active Admin is nice to have but I wouldn't say "tremendous value".

The cool thing about django admin is how easy it is to customize within the bounds that it was designed for. You have one liners to add calculated values, complex filters, inline records from related tables, a permission model to limit operations and/or access to certain objects (or records), custom actions on a set or subset of items, import/export, etc etc. 99% of it without touching HTML or CSS. If you need something more complex, you just build it, but right out of the box it provides a lot of options for the content managers. If you stay within the bounds of how it was designed, the extensibility model is solid.

A core developer of Django, I think Carlton Gibson but can't find it, mentioned in a podcast that if one were to commission the development of Django's admin interface from scratch today, it could cost around $1 million USD.

Admin for Symfony Framework ( PHP )

https://symfony.com/bundles/EasyAdminBundle/current/index.ht...

Admin for Laravel (PHP) https://nova.laravel.com/

Java Spring Boot https://docs.spring-boot-admin.com/current/getting-started.h...

I think many other Frameworks have this, did you search for it?

> Why has Django Admin proliferated so strongly in the Django ecosystem while being unreplicated elsewhere?

It's useful when I start a project, but if that project matures I generally replace it with something tailor made to the application. In other languages and framework I end up building an admin panel too, just in Django I end up doing that later in the process.

Replicating the Django admin is tough too. It's made to be highly generic and it remains stable release to release. Any project seeking to replicate that would need to replicate Djangos abstraction model in order to achieve any kind of stability like the Admin view has.

It's hard to automatically generate a useful admin dashboard like this in a framework that's not oriented around crud apps with certain assumptions baked in.

Most frameworks/platforms that are oriented around crud apps, where the framework itself does have a concept of models, do have some sort of admin dashboard feature.

Flask is a microframework that doesn't make assumptions about any database/models, so it's impossible for it to do something like this.

However, there is arguably a limited range of apps where an automatically generated admin dashboard is going to be useful anyway.

The one data point I can offer is that beat scheduler is a must have for our tiny moonlighting-as-devops squad, and that integrates perfectly with the admin panel.

So, in a word: Celery.

This also allows django tasks to be fired from other clients (other than a direct web site visit), which permits us to author tasks that can be leveraged from other containers/app instances.

Almost all CRUD ops are handled purely in the backend as like "not really django-like" implementations, which suits us perfectly - in case we want to pack up our things and move to a new framework.

Mostly because it is dangerous (or was). For example, an integer that can only be 1, 2, or 3. In the admin (way back in the day, at least), someone could go into the admin and set it to 4. Which would then break everything in subtle ways.

Also, most applications have constraints like "X can only be 2 if and only if Y is equal to Z" ... there was no way to specify that constraint to the admin interface, so someone could set X to be 2, and it would break programmer assumptions who wrote code expecting Y to be equal to Z.

It's hard to do well, especially if the framework isn't built from the ground-up to meaningfully model database schemas. It basically involves creating a CMS which is a project in of itself. Do you stop at building Django or do you keep going until you have created Wagtail? There's a ton of value in it, but it's tough.

Nova in Laravel. https://nova.laravel.com

> Beyond that, I don't think there's a clear equivalent in another language either.

Filament seems promising for folks working with Laravel:

https://demo.filamentphp.com/

I don't think it's quite there yet though. It's pretty slow.

Maybe the batteries included approach allows the ORM to synergies with the admin in a way that would be harder in other frameworks where the tooling is more ad hoc?

I think flask and fastapi are just intended to be very basic easy and quick and that's why they don't include this type of thing.

https://payloadcms.com/

For js/node

ActiveAdmin in rails

It's probably a combination of things.

The Django Admin existed before Django publicly existed. That meant that once anyone started using Django they knew that they should constrain their use of Django in certain ways so that the Django Admin would work with their usage. Features that would be added to Django would be built with the Django Admin in mind.

Many tools like Flask or FastAPI don't have an opinionated model layer like Django. Without that, you can't really create an admin interface programatically. People could be storing their data in any sort of fashion anywhere. How would one build an admin system for something like Flask or FastAPI where there's no convention around how people set up data access? A lot of frameworks out there don't tell you "access your data in this way" or "this is how users will be authenticated." Without those two things, it's hard to really create an admin system.

There are similar systems available for some frameworks, but since they aren't part of the core framework, they don't get the same attention. Someone creates it, but it doesn't have the kind of community buy-in that sustains it. One of the odd things about Django is that the admin system is under `django.contrib` which indicated that they didn't intend for it to be in the core of Django forever, but that's not really how `django.contrib` ended up. It continued to be a core part of Django maintained as part of the framework.

Like I said, there are admin dashboards available in other frameworks like RailsAdmin (https://github.com/railsadminteam/rails_admin) or Core Admin for .NET (https://github.com/edandersen/core-admin) and I'm sure there's more. However, both Rails and .NET provide most of what Django provides (and a lot more than most frameworks). Rails and .NET both have a default data access ORM that a majority of people using those frameworks tend to use. .NET has built-in authentication/authorization so the admin can work off that. Rails doesn't have auth, but RailsAdmin uses some plugins.

There's even Flask-Admin: https://flask-admin.readthedocs.io/en/latest/. However, if you start reading through the docs you start seeing that you have to solve more than just dropping it in. How do you do auth and permissions? Have you used SQLAlchemy, MongoEngine, PeeWee, or PyMango to access your data? No? Well, you might need to write a way for it to actually figure out your data. Because Flask apps aren't generally written with Flask-Admin in mind and because Flask doesn't offer a default path for things like models and auth, it becomes a harder and more varied task to create a generic admin system.