Slippers: reusable Django components without Python

Components in template syntax, with attributes and slots

Slippers describes itself as a UI component framework for Django built on top of the Django Template Language, and its pitch is to build reusable components in Django without writing a single line of Python. The example in the README shows a quote block written as a template tag with three named sections, using the opening syntax with a hash and a closing form, and the content inside is ordinary template markup plus curly quotation marks. A button works the same way, with a variant attribute and a body:

{% #Button variant="primary" %}See how it works{% /Button %}

So a component is a template file, and it is invoked with attributes and filled through named sections. The authoring is done in the template, and the framework is the convention that makes those sections and attributes resolve.

Why the Django Template Language needed augmenting

The README makes the argument for the library in plain terms, and the reasoning matters for anyone weighing it against a JavaScript component approach. The Django Template Language is described as fast, rich in features and pretty great to work with, and Slippers aims to augment it, adding just enough functionality to make building interfaces a bit more comfortable. It includes additional template tags and filters, but the headline feature is reusable components. The tradeoff is the one worth naming explicitly. A template-driven component system gives you server-rendered markup with no build step and no client runtime, which is exactly what a Django monolith often wants, and it gives up the JavaScript ecosystem of component libraries in exchange. If your team already ships a React front end, the value of this library is considerably lower, because the composition problem it solves does not exist in the same form.

Installation is a pip install and one entry in INSTALLED_APPS

The package is on PyPI and installs like any other Django application:

pip install slippers

Then it goes into your settings:

INSTALLED_APPS = [
    ...
    'slippers',
    ...
]

The dependencies in the project metadata are Django of at least 3.2, PyYAML, typeguard and typing-extensions. The classifiers are more specific than the dependency floor, listing Django 4.2, 5.0, 5.1 and 5.2, and Python from 3.8 through 3.14, with the requires-python field set to 3.8.0 or later. The Django classifier list is the one to check, because a project on a Django version outside it is not what the package claims to support even though the dependency constraint would still let it install.

YAML files define the components

The dependency on PyYAML is the visible clue to how components are declared, since a Django template library on its own has no reason to parse YAML. The repository layout supports this reading, with a slippers package directory holding the framework code and a separate directory named pygments_slippers that is not part of the published package, plus a docs directory, a tests directory and a runtests.py entry point. The static asset handling is worth noting because it is the part that affects deployment. The build configuration lists slippers/static/slippers/main.js and slippers/static/slippers/main.css among the source files included in the distribution, which means the published wheel carries static files that your project has to serve, not just Python code.

Alpha status, the release line and what is actually tested

The package metadata is candid about maturity. The development status classifier is Development Status :: 3 - Alpha, the version is 0.7.1 and the licence is MIT. The release history in the repository shows 0.6.3 on 2026-03-30, 0.7.0 on 2026-04-04 and 0.7.1 on 2026-08-13, and the last push was on 2026-08-13, the same day as the newest release. So the project is being worked on and the tag cadence in 2026 is quick by the standards of a small library, but the version number has not left the pre-1.0 range and the metadata still says alpha. The test and tooling setup is more conventional: pytest through tox, ruff for linting, a uv lock file, and GitHub Actions for code quality and tests.

Where it fits, and where it does not

The honest comparison is with the two other ways a Django project handles this. The first is writing a template include with a context dict, which is what Slippers is replacing, and the gap it closes is the loss of type checking and the ceremony of passing slots through context. The second is a client side component library with a build step, which gives you richer interaction and a real component model but requires JavaScript on the page and a second build pipeline. Slippers sits in the middle, closer to the template include, and its value is that components get attributes, slots and validation rather than a bag of context variables. Where it is the wrong tool is when your interface needs state, and where it is the right tool is when your interface is mostly server-rendered markup and you want the pieces to be reusable without leaving the template language.

Editorial conclusion

Slippers fits a Django team that wants reusable interface pieces without building a component layer in Python, and that is happy to accept the template-tag syntax as the price. It does not fit a project that has already standardised on a JavaScript component approach, or a team that considers alpha status in the package metadata a blocker. Before adopting it, read the getting started documentation on the project site to see the component model, check that your Django version falls in the supported range, and decide how you will ship the static assets, since the build configuration includes a main.js and a main.css that have to be present in your static files.

Frequently asked questions

Official sources

1. License: MIT
2. mixxorz/slippers on GitHub
3. Project website
4. README
5. Releases