Motivation

Several excellent libraries for creating components in Django exist:

[!NOTE] Also worth mentioning is django-template-partials from Carlton Gibson. While not a full component library, it allows defining reusable chunks in a Django template, providing a lightweight approach to reusability.

These libraries are excellent in their own right, each solving specific problems in innovative ways: django-components is full-featured and will take most people far with custom components, django-unicorn offers a novel approach to adding interactivity without a full JavaScript framework, and django-cotton has a new way of defining custom components that has me very excited.

So, why another Django component library?

Most of the ones above focus on defining components on the Python side, which works for many use cases. For those focusing on the HTML and Django template side, they have made significant strides in improving the developer experience. However, as a developer with strong opinions (sometimes loosely held 😄) about API design, I wanted a different approach.

After watching Caleb Porzio’s 2024 Laracon US talk introducing Flux, I could not shake the desire to bring something similar to Django. While there are plenty of libraries such as Shoelace or UI kits designed for use in any web application, and tools like SaaS Pegasus for whole Django project generation, I couldn’t find a well-polished component library solely dedicated to Django templates with the level of polish that Flux has for Laravel.

Initially, I considered contributing to existing libraries or wrapping one to add the functionality I wanted. However, I decided to create a new library for several reasons:

  1. I wanted to respect the hard work of existing maintainers and avoid burdening them with features that may not align with their project’s goals.

  2. While wrapping an existing library might have been technically feasible and okay license-wise, it didn’t feel right to build an entire component system on top of someone else’s work, especially for a project I might want to develop independently in the future.

  3. Building something new gives me the freedom to fully control the direction and architecture, without being constrained by design choices made in other libraries.

  4. Healthy competition among libraries helps drive innovation, and I see this as an opportunity to contribute to the broader Django ecosystem.

  5. Recent libraries like django-cotton and dj-angles are pushing Django templates in new and exciting directions and I wanted to join in on the fun. 😄

It’s very early days for django-bird. What you see here is laying the foundation for a template-centric approach to Django components. The current implementation focuses on core functionality, setting the stage for future features and enhancements.

See the ROADMAP for planned features and future direction of django-bird.