# Django admin not for end users? Alternatives? **URL:** \ **Category:** The Admin\ **Created:** [December 13, 2022, 10:37am UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584 "2022-12-13T10:37:39Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![mjmare](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mjmare/32/11296_2.png) [@mjmare](https://forum.djangoproject.com/u/mjmare)\ **Post date:** [December 13, 2022, 10:37am UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/1 "2022-12-13T10:37:39Z")
I would appreciate any ideas on the following: 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? TIA ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [December 13, 2022, 1:19pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/2 "2022-12-13T13:19:30Z")
> [@mjmare](#): > > Why is that so bad? First, let’s start with what the docs actually say. Quoting from [The Django admin site | Django documentation | Django](https://docs.djangoproject.com/en/4.1/ref/contrib/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. > [@mjmare](#): > > 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. 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. > [@mjmare](#): > > For many simple apps not so much. 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. ---
**Author:** ![mjmare](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mjmare/32/11296_2.png) [@mjmare](https://forum.djangoproject.com/u/mjmare)\ **Post date:** [December 14, 2022, 11:33am UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/3 "2022-12-14T11:33:28Z")
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? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [December 14, 2022, 1:32pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/4 "2022-12-14T13:32:05Z")
> [@mjmare](#): > > 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’m not entirely sure what you’re looking for here, but we use Crispy extensively. What would you expect such a “UI library” to do? ---
**Author:** ![mjmare](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mjmare/32/11296_2.png) [@mjmare](https://forum.djangoproject.com/u/mjmare)\ **Post date:** [December 14, 2022, 1:43pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/5 "2022-12-14T13:43:41Z")
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… ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [December 14, 2022, 1:58pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/6 "2022-12-14T13:58:36Z")
> [@mjmare](#): > > Something similar to Admin’s inlines. Admin inlines _are_ formsets. (See [The Django admin site | Django documentation | Django](https://docs.djangoproject.com/en/4.1/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin.formset)) > [@mjmare](#): > > And table component with more features than Django-tables We use [jQuery Datatables](https://datatables.net/) > [@mjmare](#): > > My (limited) experience with Crispy Forms is that it did not seem to be easily coupled with Tailwind. I’ve never used Tailwind. I see that there is [a media pack for it](https://github.com/django-crispy-forms/crispy-tailwind), but I have no basis for evaluating it. > [@mjmare](#): > > Maybe I should invest some more time in something like Django Unicorn… Superficially, that looks a lot like [htmx](https://htmx.org/), which I can also heartily recommend. (The combination of htmx and Channels has been a game-changer for us.) (We tried Vue off and on for about a year, and ended up deciding the additional cognitive load required for it was not worth the effort invested.) ---
**Author:** ![mjmare](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mjmare/32/11296_2.png) [@mjmare](https://forum.djangoproject.com/u/mjmare)\ **Post date:** [December 14, 2022, 2:05pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/7 "2022-12-14T14:05:21Z")
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. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [December 14, 2022, 3:37pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/8 "2022-12-14T15:37:35Z")
> [@mjmare](#): > > I thought jQuery was old school. 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. > [@mjmare](#): > > Do you know of some Django integration or article? We use [django-datatables-view · PyPI](https://pypi.org/project/django-datatables-view/). 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. > [@mjmare](#): > > Do you use Bootstrap with Crispy? Yes. We use Bootstrap exclusively. > [@mjmare](#): > > Looks tempting, but it seems to lead to duplication and scattering of template fragments. 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. ---
**Author:** ![mjmare](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/mjmare/32/11296_2.png) [@mjmare](https://forum.djangoproject.com/u/mjmare)\ **Post date:** [December 14, 2022, 4:25pm UTC](https://forum.djangoproject.com/t/django-admin-not-for-end-users-alternatives/17584/9 "2022-12-14T16:25:01Z")
Thx for this conversation. Really useful.