Why has Django Admin proliferated so strongly in the Django ecosystem while being unreplicated elsewhere?
That's one of the reasons it doesn't support things like compound primary keys very well - it turns out you don't really need those for the common CMS subset of functionality.
I totally agree though- huge selling point of Django!
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.
Citation needed. We also have got a _lot_ of mileage out of it over the years.
In short you really can give it to knowledgeable admins at customers to configure and admin applications with, in a way that you can't just let them edit database tables.
As with all frameworks, the freebies usually have less value in real world situations than we imagine they would.
So choosing a framework based on the freebies is extra risky.
A few key features in terms of data entry:
- custom data validation
- ability to edit foreign key and many-to-many relationships, with optional search
- inline editing of related items
- file uploads
- custom "actions", where you can select a bunch of rows at once and then run custom logic to process them in some way
Even writing a fully custom “admin” interface for one part of a business process isn’t usually much work if the system itself (which Django would also depend on) is reasonably designed.
Writing something from scratch isn’t that difficult, and you get exactly what you need without fighting against the framework.
But whether starting from a scaffold of another framework or building entirely custom, the effort in making custom, complex admin interfaces isn’t difficult.
As with most software systems, the biggest part of the work is dealing safely with end users. Admin interfaces can be simpler because of this, and therefore they are less effort to make.
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.
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 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 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.
My opinion is that once you add a dependency to your project, you own it just like your own code. This means understanding it enough to know how it’s built, but for the time being, someone else is maintaining it. And that a donation every once in a while should be made if it’s a core part of your product.
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".
I recently dabbled a bit in stock picking, and built a system to record my commentaries on stocks and my subjective valuation, so that I can refer to them later (so that I have something to base my trades on other than pure emotion).
I just defined the models and used the admin interface for all the editing. I mean, in theory it's not much different from using an excel spreadsheet to keep my records, but I get a full SQL database and a customizable webUI for free after I defined my models. And if I need anything fancy I have a fully programmable system that I can extend arbitrarily.
In django, as long as the functionality is only exposed to trusted users (hence it's called "admin"), there's very little reason to write any "views" logic after you defined the model and basic controller logic.
It's basically the generic CRUD app that you don't have to write.
The admin has a a LOT of features.
More importantly, it's been continuously evolving for nearly 20 years at this point.
Anyone who's actually tried to do a from-scratch rewrite of a system that has 20 years of development behind it will know that 5 engineers for a year is probably optimistic!
200k/year might sound like a lot but then in a real business there are various overhead costs as well.
I'd say $1m is probably on the lower side of the estimate. Factoring in project delays and misc Murphy law things, wouldn't be surprised if a mediocre team underdelivers with a crappy immitation of the django admin interface after blowing through a couple mil.
Add on top of that documentation, testing, and making the whole thing completely independent and pluggable (as django must work without it) but perfectly integrated with it (settings, forms, template overrides, etc).
That's a lot.
You might get feature parity with less, but not with the same guarantees of stability and maturity.
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?
Super-simple to set up and it's been perfectly adequate for my app's needs so far.
To answer OP's original question: Django Admin isn't a killer feature because the same kind of thing is available for most other Django-like frameworks, with the only difference being that it's usually a third party library rather than something built into the framework itself.
The problem with third-party libraries for this kind of thing is that there's no guarantee that they will be maintained in lockstep with the underlying framework.
What if they get abandoned? Or a new version of the framework comes out with new features but the third-party library takes months to add support for them?
I think this may be an aspect of Django that isn't appreciated nearly as much as it should be: batteries included means that the feature you depend on are guaranteed to be maintained and documented at the same pace as the rest of the framework.
This is a paid product whereas Django Admin is a part of Django.
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.
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.
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.
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.
This is a convention though - one could just as easily do it the other way and embed all the business rules in the models.
(You still have to do the work, but if people are breaking things through the admin that's your fault.)
It's decent overall, but I think filament and orchid are overall a better value. Both because they're free but feel a bit easier to work with, and seem to have faster-growing ecosystems.
Filament seems promising for folks working with Laravel:
I don't think it's quite there yet though. It's pretty slow.
1. The docs for going from v2 to v3 were woefully incomplete unless you were using only basic v2 features. Unnecessarily painful.
2. Speed is relative. For people coming from WordPress or other systems, it’s just fine if you do some basic optimization.
3. If you’re going to use it outside of the Admin Panels in the rest of your app… structure appropriately. It’s not a skill taught in the documentation but is vital. It’s easy to make a mess.
For js/node
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.
While I was looking for something for us to upgrade off of Django admin to, it seems like the main presence here is something like ReTool or Airplane.dev. The common consensus in these tools seems to be that the way to build admin dashboards in a framework-agnostic way is to build drag'n'drop interfaces and then have lots of little individually deployable scripts which run SQL queries.
This seems like such a sad state of affairs. Do you know of any tools that are able to cope with data storage agnosticism in a way that feels more like software engineering?
I was going to question the "tremendous value of Django Admin", but I thought I shouldn't. I was going to say something along the lines that it creates this mediocre form inputs so that backend engineers don't have to write an HTML form and they can ship something to their users without having to touch the front-end. However, I actually do agree that there is a good amount of value in the Django Admin. Having a mediocre UI to touch the data is really valuable. I think the problem is that you start thinking it should be the only UI for touching the data.
The solution to your problem might be creating something custom with some utilities. What does the Django Admin offer you? A way of displaying a table of data? A link to a form to update that data? You could build what you need.
I'm not sure what you're looking for in terms of something "that feels more like software engineering." I don't even know what your use case is for the Django Admin. Are you a shop doing lots of small projects for clients so you need a way for them to edit the data that looks passably professional while taking the absolute minimum of dev time? Are you creating a single product and maybe you should just spend a little bit more time on data access? Why do you want something that "feels like software engineering?"
At some point, there might be cases where you simply need custom stuff for certain things.
The use case is https://spotdx.com. We're a YC backed healthtech product with a significant amount of need for safe manual data entry and updates, and the requirements for that data entry evolves semi-frequently. Compared to a traditional frontend framework (say, React), Django Admin drastically slashes the amount of engineering resources needed to ship new kinds of mediocre form input. The way we work at the moment doesn't require a frontend engineer at all to get new internal stuff done.
There's a lot of cool work that has been done across various frameworks to put CRUD interfaces of varying complexity on top of an ORM, but it all seems so repeated and fragmented, and varies wildly in quality between frameworks. I wish there was a tool like ReTool that was tied to our regular backend and ORM.
We do use React for other parts of our product, but avoiding it here is handy.
You're right: the other tools often aren't amazing and part of that is because critical mass makes things better. The fact that the Django Admin is so common in the Django world means that it gets exposed to many different use cases and things work pretty well with it.
To take a step back, some of this is the framework vs. library debate. With a framework, you're getting libraries where the edges between the libraries have been smoothed over and there's a certain assurance that things will work together well. With a library, it can be a very high-quality library, but it can feel like it doesn't quite work with your stuff. Part of that is that it's hard to anticipate everything people will do.
I am curious what you like about ReTool and what you don't. It sounded like you wanted something that felt more like software engineering than like ReTool's low-code drag-and-drop experience, but maybe I'm wrong. In terms of being integrated with your regular backend and ORM: is the point that you want it (for example) to be able to re-use filters you've already set up in a model and therefore if you update those filters in the future, you don't have to also update them in whatever query ReTool is using?
I think part of the issue is that the Django Admin serves what most people need and once they go beyond that, they'll just hook in a tiny bit of custom stuff. I haven't used Django since before the pandemic so I don't remember everywhere you can hook into the admin system, but I kinda remember being able to being able to create custom pages in `admin/model-name/custom-view-name.html` and then being able to do a custom view that used the Django auth (https://docs.djangoproject.com/en/4.2/topics/auth/default/#t...). Maybe the answer for the bulk stuff is simply doing your own list-view for the occasions you need it. For example, if you want to have a form field that's like "Update all names to what's in the box", you could just override the template for that model, create a little form at the top, have it submit to a custom action within the admin that does the work, and then redirects back. Again, it's been a while since I've used Django, but you can always extend things like `django.contrib.admin.views.main.ChangeList`. I also don't completely understand your use case because we're just having a very small conversation on HN so my comment might be completely off base. But I remember just extending the existing Django stuff and overriding stuff.
I'd also say that sometimes it can be helpful to take a step back and think if there's a different way of getting to where you're trying to go. If there's something that you need that happens kinda rarely, you can always create a new page within the section for that model and then have a link to that page. Then just do custom stuff there. Are your requirements that go beyond what the Django admin can do something that you're running into constantly or something that's blocking you on a couple of tiny edge cases? If it's the latter, maybe stuff a custom Django admin view in a couple places.
Ultimately, I think the issue is that open source often stops at a certain point. Tools like ReTool are built to scratch a different itch: the itch for enterprise businesses that want a low-code solution and are willing to pay someone to abstract a lot of stuff. In the open source world, things often stop way short of what the Django admin offers - heck, that's the entire thesis of your initial post. It's hard to create good, general tools because everyone wants something slightly different and you end up building your own mini-programming language as it gets general enough. The companies/people who try to go that route are generally targeting enterprise executives and not software engineers. But I certainly understand wishing that the Django Admin just did things a little different or a little better.
Hi from Retool! I'm working on an exact solution for this problem. We're building a backend & ORM integration that will enable you to connect your ORM with Retool directly to build admin dash & flexible tools on top of it. It's beta but please let me know if you would like to give it a try!
If your data is in pg/mysql/sqlite/clickhouse this might work for you
That is for js/ts stack