The Django admin is very useful. So useful in fact, that for quite a few (internal) apps it is sufficient with a bit of tweaking. But then one reads the warning not to use expose end users to the Admin.
Why is that so bad?
The step from the Admin to a custom UI is quite big. When creating a specialised app that is worth doing. For many simple apps not so much.
If one does not use the Django Admin for end users are there any 3rd party libraries that give the rapid development advantage of the Admin?
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.
and
If you need to provide a more process-centric interface that abstracts away the implementation details of database tables and fields, then it’s probably time to write your own views.
To be precise then, they don’t say “don’t expose it to end users” - depending upon your definition of an “end user” in this context. It’s saying it shouldn’t be your only UI.
So there are three explanations that I am aware of for this.
If your UI needs get sophisticated enough, either regarding what you are going to display or how you are going to display it, you will find that it ends up being a lot more work to twist the admin into doing exactly what you want done. I have seen multiple examples of people creating ModelAdmin classes that are 3 to 4 times the size of a view needed to perform the same functions.
The admin is designed as your ultimate “fix-it” tool. If you need to make unforseen data changes, you do not want some admin customizations in your way, preventing you from fixing something that needs to be fixed. It’s a whole lot easier and safer for a site admin to be able to use the admin to fix problems than it is to require them to make changes directly in the database using other tools, simply because the functionality they need is no longer available through the admin.
Providing proper security within the admin for your application can be difficult, depending upon your security requirements.
In part, it depends upon what you mean by a “simple” app. A one-table BREAD app is very little code overall, and not “quite big”. You can even use the admin base template as your base if you want your UI to generally look like the admin pages, or use the same javascript and css to provide the same themeing.
One thing I’ve learned as a universal constant across 40+ years in this business is that “simple apps” don’t tend to remain simple over time.
The situation I described in my first point comes from people starting out thinking “Oh, I can do all this in the admin”. But then real-world requirements start creeping in. As each new feature gets added, you’re doing more and more work to try and make the admin do what you need it to do. You will reach a point where the time and effort you are putting into the admin exceeds the amount of work it would have been by starting out with user-written views.
The key here then is recognizing when it’s time to ditch the admin as your core UI and start adopting a custom UI.
Thanks Ken, for your extensive and thoughtful response.
I think you hit the nail on the head: the challenge is to know when it is time to stop using the Admin and create a custom UI. In a way the admin is a curse: very easy to get started with, luring you in, in a way.
I think a solution, or middle ground, would be to have an extensive UI library for Django, that makes it (almost) as easy to get started writing your own UI.
I know this is not made easier with the plethora of front end CSS and JS libraries (Bootstrap/Tailwind).
Are you aware of such libraries, or do you always run your own?
I guess some high level components for selecting 1-to-1, 1-to-many relations. Something similar to Admin’s inlines. And table component with more features than Django-tables (equivalent to, or using something like tabulator.info) would be useful.
My (limited) experience with Crispy Forms is that it did not seem to be easily coupled with Tailwind. Django tweaks was more helpful in that regard. And Crispy’s Bootstrap 5 support seemed a bit experimental.
In the past I used a Vue based framework Quasar (quasar.dev), which has a ton of components. These components made it very easy to whip up a UI. I do not like javascript, but Quasar made it palatable.
Maybe I should invest some more time in something like Django Unicorn…
Thanks again Ken.
jQuery Tables looks nice. I thought jQuery was old school. Do you know of some Django integration or article?
Vue’s single page templates (or whatever it is called) are nice. But I agree that the complexity grows exponentially (as with all SPA frameworks).
Do you use Bootstrap with Crispy?
HTMX, I don’t know yet what I think about it. Looks tempting, but it seems to lead to duplication and scattering of template fragments. Haven’t used it in earnest yet.
It does have that reputation. Personally I don’t consider that, by itself, to be a “bad thing”. It works well, does what we need it to do, and doesn’t add all the complexity of the SPA-oriented frameworks. Plus, add htmx into the mix and the amount of code you end up writing is really quite small.
We use django-datatables-view · PyPI. There are some others. Datatables can do a lot, what you pick to use it with depends a lot upon what features of Datatables you wish to use.
We rely heavily upon the AJAX features for data. The page is loaded without any data - only the table definition. Inside the table definition is the ajax url for populating the table.
Yes. We use Bootstrap exclusively.
Our experience has been that it reduces duplication among templates, but it does create more template files. HTMX is going to call a view - that view can load data from a database, and supply it to the rendering engine in the context to be rendered with the template. That permits a lot of flexibility in how that template is going to be rendered.
Or, in some cases, we have even eliminated the use of templates when the div being updated is an atomic value.