Django Material: Material Design 3 components and CRUD views for Django

The problem Django Material solves for Django developers

Django ships an admin, but not a component library. Anything beyond the default admin means writing templates, wiring a CSS framework, and rebuilding the frontend toolchain. Django Material targets that gap: it packages Material Design 3 components (buttons, cards, forms, tables, navigation) and full list, create, update and delete views, styled and ready to extend. It is aimed at Django developers building internal tools, dashboards and CRUD-heavy apps who do not want React, Vue or Angular in the stack. The README also states an unusual design goal: component APIs intended to be predictable for code generation tools as well as for humans. That is a positioning statement, not a feature you can verify from the repository, but it explains why the component surface is small and tag-based rather than Python-class-heavy.

How django-cotton tags and Unpoly drive the interface

The mechanism is layered. Component markup lives in material/templates/cotton/, where django-cotton exposes each component as a tag such as <c-button.filled> or <c-card>. django-cotton is a hard dependency in pyproject.toml, alongside django-filter, so the component syntax is not optional. Styling is TailwindCSS compiled ahead of time into material/static/material/css/material.css, which is why the README claims no build step is required to use the library: the built CSS and JS ship inside the package. The JavaScript bundle is built by esbuild from material/templates/cotton/index.js into material/static/material/js/material.js, and the README attributes SPA-like page updates to Unpoly.js. So the data flow is ordinary Django: a view renders a template, the template composes cotton components, and Unpoly intercepts navigation to swap page fragments instead of doing full reloads. Nothing here replaces Django's request cycle. If you already use django-cotton, the integration cost is low; if you do not, you are adopting a second template language convention on top of Django's.

Installing Django Material and rendering a first component

The README gives a four-step quickstart. Install the package with pip, then register it in INSTALLED_APPS.

pip install django-material

INSTALLED_APPS = [
    # ...
    'material',
    # ...
]

For production, the README says to collect static files so material.css and material.js are served.

python manage.py collectstatic

Then extend the base template and drop in a component. The README uses the filled button tag inside a content block.

{% extends "material/base.html" %}
{% block content %}
  <c-button.filled>Start Building</c-button.filled>
{% endblock %}

If the tag renders as literal text rather than a button, django-cotton is not resolving the component, which is the first thing to check. Note the version: pyproject.toml declares 3.0.0a0 and the classifiers mark Development Status as Alpha, so a pip install may not give you the code shown in the README if your index serves an older release. The README points to material.viewflow.io for documentation and live demos, and the repository contains a demo/ project with its own settings.py and urls.py if you want a working reference instead of assembling one.

Where Django Material is the wrong tool

The README opens with a warning that APIs, components and behavior may change between versions, and recommends use for exploration and prototyping with careful evaluation before production. That is the project's own assessment, and it should be read literally. Two consequences follow. First, pinning is mandatory: because the package is at 3.0.0a0, a minor bump can rename a component tag, and every template using it breaks at render time rather than at import time. Second, the dependency chain is narrow. requires-python is >=3.12 and django>=5.2, so projects on Django 4.x or Python 3.11 cannot use it at all. No release history was retrieved, which means you cannot read a changelog of breaking changes before upgrading; the pyproject.toml lists a Changelog URL pointing at GitHub releases, but nothing was retrieved from it. If your team needs a stable admin theme with a long support window, this is not that. If you need a component system that works outside Django's template engine, this is also not that, since the components are Django templates and nothing else.

Django Material compared with Jazzmin and Unfold

Related searches put Django Material next to django-jazzmin and django-unfold, and the difference is scope rather than taste. Jazzmin and Unfold are admin skins: they restyle Django's existing admin site and leave your own views alone. Django Material goes further in one direction and less far in another. It ships components you can use in any template, plus list, create, update and delete views, so it is trying to be the UI layer of your application, not just the admin. But it does not claim to reskin the built-in admin, and the README's feature list is about components and CRUD views, not admin customization. If your goal is a nicer Django admin with zero template changes, a skin is the smaller commitment. If your goal is a consistent Material interface across admin-adjacent CRUD screens, Django Material is addressing that directly. The trade-off is the alpha status and the django-cotton dependency, neither of which the skinning tools impose.

Licence, maintenance and the cost of upgrading

The repository LICENSE is AGPL-3.0, and pyproject.toml declares AGPL-3.0-or-later. The README adds that the project is licensed under AGPLv3 with Additional Permissions, pointing at LICENSE_EXCEPTION, and mentions commercial terms in COMM-LICENSE. Both files exist at the repository root. AGPL-3.0 is a network copyleft licence, so if you run a modified version as a network service, the licence's source-availability obligations are the question your legal counsel needs to answer; the Additional Permissions in LICENSE_EXCEPTION may change that answer, and COMM-LICENSE suggests an alternative path. I am not giving legal advice here, only naming the files to read. On maintenance: the last push to the default branch was on 2026-05-02, and the repository is not archived. With no release history to read, upgrade cost is hard to estimate from the outside. What is verifiable is the version string 3.0.0a0 and the alpha classifier, which together mean you should expect to read diffs rather than release notes before moving versions.

Editorial conclusion

Adopt Django Material if you are prototyping a Django admin or CRUD interface and want Material Design 3 without a frontend framework, and if you can absorb API churn. Do not adopt it for a production interface that must stay stable across upgrades. Verify first that django-cotton resolves your component tags, that collectstatic picks up material.css and material.js, and that the AGPLv3 plus Additional Permissions terms in LICENSE_EXCEPTION fit your distribution model.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. viewflow/django-material on GitHub