Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

djust

Reactive server-side rendering for Django, powered by Rust

djust brings Phoenix LiveView-style reactive components to Django. You write server-side Python; the client updates automatically over a WebSocket. There is no JavaScript to write, no bundler, and no build step in your project.

djust.org · Documentation · Quick Start · Examples

PyPI version CI MIT License Python 3.10+ Django 4.2+ PyPI Downloads

Features

  • Fast — Rust-powered template engine and virtual DOM diffing (roughly 7–11x faster than Django on variable- and filter-heavy templates, and no faster on static markup; see Performance)
  • Reactive components — Phoenix LiveView-style server-side reactivity
  • Django compatible — works with existing Django templates and components
  • No build step — ~58 KB gzipped client JavaScript, no bundling required
  • WebSocket updates — real-time DOM patches over WebSocket, with HTTP fallback
  • Minimal payloads — diffing sends only what changed
  • Rust core — performance-critical paths (templates, VDOM, parsing) are written in Rust
  • Debug panel — interactive debugging with event history and VDOM inspection
  • Lazy hydration — defer WebSocket connections for below-the-fold content to reduce memory
  • TurboNav compatible — works with Turbo-style client-side navigation
  • PWA support — offline-first Progressive Web Apps with automatic sync
  • Multi-tenant — tenant isolation for SaaS architectures
  • Auth — view-level and handler-level authorization via Django permissions

Quick Example

from djust import LiveView, event_handler

class CounterView(LiveView):
    template_string = """
    <div>
        <h1>Count: {{ count }}</h1>
        <button dj-click="increment">+</button>
        <button dj-click="decrement">-</button>
    </div>
    """

    def mount(self, request, **kwargs):
        self.count = 0

    @event_handler
    def increment(self):
        self.count += 1  # Automatically updates client

    @event_handler
    def decrement(self):
        self.count -= 1

No JavaScript needed. State changes trigger minimal DOM updates automatically.

How Reactivity Works

djust uses a Rust-powered virtual DOM (VDOM) to diff server-rendered HTML and send only the changed patches over WebSocket. A few core attributes make everything click.

Template Anatomy

{% load live_tags %}
<!DOCTYPE html>
<html>
<head>
    {% djust_client_config %}        {# Emits client config meta tags; djust auto-injects the client runtime #}
</head>
<body dj-view="{{ dj_view_id }}">   {# Identifies the WebSocket session #}
    <div dj-root>                    {# Reactive boundary — only this is diffed #}
        <h1>Count: {{ count }}</h1>
        <button dj-click="increment">+</button>
    </div>
    {# Static content outside dj-root is never touched by VDOM patching #}
</body>
</html>
Attribute Where Purpose
{% djust_client_config %} <head> Emits client config meta tags; djust auto-injects the ~58 KB gz client runtime into every LiveView response — no manual <script> tag needed
dj-view="{{ dj_view_id }}" <body> Connects page to WebSocket session
dj-root Inner <div> Marks the reactive region; only HTML inside is diffed and patched

Stable List Identity

For lists that can reorder or have items inserted/deleted, add data-key or dj-key on each item. djust uses this to emit MoveChild patches instead of remove-then-insert pairs, preserving DOM state (focus, scroll position, animations):

{% for item in items %}
<div data-key="{{ item.id }}">
    {{ item.name }}
    <button dj-click="delete" data-item-id="{{ item.id }}">Delete</button>
</div>
{% endfor %}

Without a key, djust diffs by position — correct, but it produces more DOM mutations for reorders.

Common Pitfall: One-Sided {% if %} in Class Attributes

Using {% if %} without {% else %} inside an HTML attribute value can cause VDOM patching misalignment, because of djust's branch-aware div-depth counting:

{# WRONG: one-sided if inside class attribute #}
<div class="card {% if active %}active{% endif %}">

{# CORRECT: use full if/else #}
<div class="card {% if active %}active{% else %}{% endif %}">

{# ALSO CORRECT: move conditional outside the tag #}
{% if active %}
<div class="card active">
{% else %}
<div class="card">
{% endif %}
    ...
</div>

This applies only to attribute values — {% if %} blocks in element content work fine.

See the VDOM Architecture guide and Template Cheat Sheet for full details.

Getting Started

A complete walkthrough from zero to a working reactive counter in five steps.

Step 1 — Install

pip install djust django-channels

Step 2 — Add to INSTALLED_APPS and configure settings

In myproject/settings.py:

INSTALLED_APPS = [
    # ... your existing apps ...
    'channels',   # WebSocket support
    'djust',
]

ASGI_APPLICATION = 'myproject.asgi.application'

CHANNEL_LAYERS = {
    'default': {
        'BACKEND': 'channels.layers.InMemoryChannelLayer',
    }
}

Step 3 — Configure asgi.py

Replace myproject/asgi.py with:

import os
from django.core.asgi import get_asgi_application
from channels.routing import ProtocolTypeRouter, URLRouter
from channels.auth import AuthMiddlewareStack
from djust.websocket import LiveViewConsumer
from django.urls import path

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')

application = ProtocolTypeRouter({
    "http": get_asgi_application(),
    "websocket": AuthMiddlewareStack(
        URLRouter([
            path('ws/live/', LiveViewConsumer.as_asgi()),
        ])
    ),
})

Step 4 — Add the URL route

In myproject/urls.py:

from django.urls import path
from myapp.views import CounterView

urlpatterns = [
    path('counter/', CounterView.as_view(), name='counter'),
]

Step 5 — Write the view and template

myapp/views.py:

from djust import LiveView, event_handler

class CounterView(LiveView):
    template_name = 'counter.html'

    def mount(self, request, **kwargs):
        self.count = 0

    @event_handler
    def increment(self):
        self.count += 1

    @event_handler
    def decrement(self):
        self.count -= 1

myapp/templates/counter.html:

{% load live_tags %}
<!DOCTYPE html>
<html>
<head>
    <title>Counter</title>
    {% djust_client_config %}
</head>
<body dj-view="{{ dj_view_id }}">
    <div dj-root>
        <h1>Count: {{ count }}</h1>
        <button dj-click="increment">+</button>
        <button dj-click="decrement">-</button>
    </div>
</body>
</html>

Run with uvicorn myproject.asgi:application --reload and open /counter/. Clicking the buttons updates the count without a page reload — no JavaScript written, no build step.

Next steps:


Performance

Full render throughput, same template on both engines, parsed once on each side. Measured with benchmarks/benchmark.py on an Apple silicon laptop, Django 5.2.16 / Python 3.12, DEBUG=False, release build:

Template shape Rows Django djust Speedup
Static markup (no variables) 100 0.03 ms 0.03 ms 1.0x
Static markup (no variables) 10,000 2.85 ms 2.81 ms 1.0x
Simple list (2 vars/row) 100 0.62 ms 0.09 ms 6.8x
Simple list (2 vars/row) 10,000 63.7 ms 8.96 ms 7.1x
Filtered list (typical page) 100 2.32 ms 0.21 ms 10.8x
Filtered list (typical page) 10,000 241 ms 21.5 ms 11.2x

The speedup depends entirely on what the template does. Static markup is string concatenation and there is nothing to accelerate — djust is not faster, and says so. The advantage grows with variable and filter density, which is the direction real pages go.

Two things this table does not measure, both of which matter:

  • The VDOM patch. On an update djust re-renders and sends a diff, where Django can only re-render and ship the whole page. The wire-size difference is not in these numbers at all.
  • The round trip. WebSocket transport, diffing and client apply are excluded.

Run it yourself:

make build          # release build — a debug build reverses the result
python benchmarks/benchmark.py

The script refuses to run against a debug extension. make dev-build produces an unoptimized one that is roughly 7.6x slower and measures Django as the faster engine; since that is what most test workflows build, it is an easy and badly misleading mistake to make.

Installation

Prerequisites

  • Python 3.10+
  • Django 4.2+
  • Rust 1.70+ (only required when building from source)

Install from PyPI

pip install djust

Build from Source

Using Make (recommended for development)

# Clone the repository
git clone https://github.com/djust-org/djust.git
cd djust

# Install Rust (if needed)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Install everything and build
make install

# Start the development server
make start

# See all available commands
make help

Common Make commands:

  • make start — start development server with hot reload
  • make stop — stop the development server
  • make status — check if the server is running
  • make test — run all tests
  • make clean — clean build artifacts
  • make help — show all available commands

Using uv

# Clone the repository
git clone https://github.com/djust-org/djust.git
cd djust

# Install Rust (if needed)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Install uv (if needed)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create virtual environment and install dependencies
uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

# Install maturin and build
uv pip install maturin
maturin develop --release

Using pip

# Clone the repository
git clone https://github.com/djust-org/djust.git
cd djust

# Install Rust (if needed)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Create virtual environment
python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

# Install maturin
pip install maturin

# Build and install
maturin develop --release

# Or build a wheel
maturin build --release
pip install target/wheels/djust-*.whl

Documentation

The full documentation lives at docs.djust.org. The sections below cover the core API; see Getting Started above for first-time setup.

Creating LiveViews

Class-Based LiveView

from djust import LiveView, event_handler

class TodoListView(LiveView):
    template_name = 'todos.html'  # Or use template_string

    def mount(self, request, **kwargs):
        """Called when view is first loaded"""
        self.todos = []

    @event_handler
    def add_todo(self, text):
        """Event handler — called from client"""
        self.todos.append({'text': text, 'done': False})

    @event_handler
    def toggle_todo(self, index):
        self.todos[index]['done'] = not self.todos[index]['done']

Function-Based LiveView

from djust import live_view

@live_view(template_name='counter.html')
def counter_view(request):
    count = 0

    def increment():
        nonlocal count
        count += 1

    return locals()  # Returns all local variables as context

Template Syntax

djust supports Django template syntax with event binding:

<!-- Variables -->
<h1>{{ title }}</h1>

<!-- Filters (all 57 Django built-in filters supported) -->
<p>{{ text|upper }}</p>
<p>{{ description|truncatewords:20 }}</p>
<a href="?q={{ query|urlencode }}">Search</a>
{{ body|urlize }}  {# No |safe needed — djust auto-marks urlize output as safe (see note below) #}

<!-- Control flow -->
{% if show %}
    <div>Visible</div>
{% endif %}

{% if count > 10 %}
    <div>Many items!</div>
{% endif %}

{% for item in items %}
    <li>{{ item }}</li>
{% endfor %}

<!-- URL resolution -->
<a href="{% url 'myapp:detail' pk=item.id %}">View</a>

<!-- Template includes -->
{% include "partials/header.html" %}

<!-- Event binding -->
<button dj-click="increment">Click me</button>
<input dj-input="on_search" type="text" />
<form dj-submit="submit_form">
    <input name="email" />
    <button type="submit">Submit</button>
</form>

Django migration note: In standard Django, urlize requires |safe to render its HTML output. djust's Rust template engine automatically marks urlize, urlizetrunc, and unordered_list as safe (via safe_output_filters in the renderer), because these filters handle their own HTML escaping internally. Adding |safe after them is unnecessary.

Supported Events

  • dj-click — click events
  • dj-input — input events (passes value)
  • dj-change — change events (passes value)
  • dj-submit — form submission (passes form data as a dict)

Reusable Components

djust includes a component system with automatic state management and stable component IDs.

Basic Component Example

from djust.components import AlertComponent

class MyView(LiveView):
    def mount(self, request):
        # Components get automatic IDs based on attribute names
        self.alert_success = AlertComponent(
            message="Operation successful!",
            type="success",
            dismissible=True
        )
        # component_id automatically becomes "alert_success"

Component ID Management

Components automatically receive a stable component_id based on their attribute name in your view, which eliminates manual ID management:

# When you write:
self.alert_success = AlertComponent(message="Success!")

# The framework automatically:
# 1. Sets component.component_id = "alert_success"
# 2. Persists this ID across renders and events
# 3. Uses it in HTML: data-component-id="alert_success"
# 4. Routes events back to the correct component

Why it works:

  • The attribute name (alert_success) is already unique within your view
  • It's stable across re-renders and WebSocket reconnections
  • Event handlers can reference components by their attribute names
  • No manual ID strings to keep in sync

Event routing example:

class MyView(LiveView):
    def mount(self, request):
        self.alert_warning = AlertComponent(
            message="Warning message",
            dismissible=True
        )

    @event_handler
    def dismiss(self, component_id: str = None):
        """Handle dismissal — automatically routes to correct component"""
        if component_id and hasattr(self, component_id):
            component = getattr(self, component_id)
            if hasattr(component, 'dismiss'):
                component.dismiss()  # component_id="alert_warning"

When the dismiss button is clicked, the client sends component_id="alert_warning", and the handler uses getattr(self, "alert_warning") to find the component.

Creating Custom Components

from djust import LiveComponent, event_handler
from djust.components import register_component

class ButtonComponent(LiveComponent):
    template = '<button dj-click="on_click" data-component-id="{{ component_id }}">{{ label }}</button>'

    def mount(self, **kwargs):
        self.label = kwargs.get("label", "Click")
        self.clicks = 0

    @event_handler()
    def on_click(self, **kwargs):
        self.clicks += 1
        self.trigger_update()

    def get_context_data(self):
        return {"label": self.label, "clicks": self.clicks}

# register_component accepts LiveComponent subclasses (stateful, event-driven)
register_component('my-button', ButtonComponent)

Decorators

from djust import LiveView, event_handler, reactive

class MyView(LiveView):
    @event_handler
    def handle_click(self):
        """Marks method as event handler"""
        pass

    @reactive
    def count(self):
        """Reactive property — auto-triggers updates"""
        return self._count

    @count.setter
    def count(self, value):
        self._count = value

Configuration

Configure djust in your Django settings.py:

LIVEVIEW_CONFIG = {
    # Transport mode
    'use_websocket': True,  # Set to False for HTTP-only mode (no WebSocket dependency)

    # Debug settings
    'debug_vdom': False,  # Enable detailed VDOM patch logging (for troubleshooting)

    # Serialization (issue #292)
    'strict_serialization': False,  # Raise TypeError for non-serializable state values (recommended in development)

    # CSS Framework
    'css_framework': 'bootstrap5',  # Options: 'bootstrap5', 'tailwind', None
}

Common configuration options:

Option Default Description
use_websocket True Use WebSocket transport (requires Django Channels)
debug_vdom False Enable detailed VDOM debugging logs
strict_serialization False Raise TypeError for non-serializable state (recommended in dev)
css_framework 'bootstrap5' CSS framework for components

CSS framework setup. For Tailwind CSS, use the one-command setup:

python manage.py djust_setup_css tailwind

This auto-detects template directories, creates config files, and builds your CSS. For production:

python manage.py djust_setup_css tailwind --minify

See the CSS Framework Guide for detailed setup instructions, Bootstrap configuration, and CI/CD integration.

Debug mode. When troubleshooting VDOM issues, enable debug logging:

# In settings.py
LIVEVIEW_CONFIG = {
    'debug_vdom': True,
}

# Or programmatically
from djust.config import config
config.set('debug_vdom', True)

This logs:

  • Server-side: patch generation details (stderr)
  • Client-side: patch application and DOM traversal (browser console)

State Management

djust provides Python-only state management decorators that remove the need for manual JavaScript.

Quick Start

Build a debounced search in eight lines of Python (no JavaScript):

from djust import LiveView
from djust.decorators import debounce

class ProductSearchView(LiveView):
    template_string = """
    <input dj-input="search" placeholder="Search products..." />
    <div>{% for p in results %}<div>{{ p.name }}</div>{% endfor %}</div>
    """

    def mount(self, request):
        self.results = []

    @debounce(wait=0.5)  # Wait 500ms after typing stops
    def search(self, query: str = "", **kwargs):
        self.results = Product.objects.filter(name__icontains=query)[:10]

The server only queries after you stop typing. Add @optimistic for instant UI updates, or @cache(ttl=300) to cache responses for five minutes.

See the State Management Quick Start.

Available Decorators

Decorator Use When Example
@debounce(wait) User is typing Search, autosave
@throttle(interval) Rapid events Scroll, resize
@optimistic Instant feedback Counter, toggle
@cache(ttl, key_params) Repeated queries Autocomplete
@client_state(keys) Multi-component Dashboard filters
@background Long operations AI generation, file processing
DraftModeMixin Auto-save forms Contact form

Quick decision guide:

  • Typing in an input? → @debounce(0.5)
  • Scrolling/resizing? → @throttle(0.1)
  • Need an instant UI update? → @optimistic
  • Same query multiple times? → @cache(ttl)
  • Multiple components? → @client_state([keys])
  • Long-running work? → @background or self.start_async(callback)
  • Auto-save forms? → DraftModeMixin

More documentation:

Navigation Patterns

djust provides three navigation mechanisms for building multi-view applications without full page reloads:

When to Use What

Scenario Use Why
Filter/sort/paginate within same view dj-patch / live_patch() No remount, URL stays bookmarkable
Navigate to a different LiveView dj-navigate / live_redirect() Same WebSocket, no page reload
Link to non-LiveView page Standard <a href> Full page load needed

Quick Decision Tree

Is this a direct user click on a link?
├─ Yes → Is it the same view (filter/sort)?
│   ├─ Yes → Use dj-patch
│   └─ No → Use dj-navigate
│
└─ No → Is navigation conditional on server logic?
    ├─ Yes → Use live_redirect() in @event_handler
    │   Examples: form validation, auth checks, async operations
    └─ No → You probably need dj-navigate (see anti-pattern below)

Anti-Pattern: Don't Use dj-click for Navigation

This is the most common mistake when building multi-view djust apps. Using dj-click to trigger a handler that immediately calls live_redirect() creates an unnecessary round-trip.

Wrong — using dj-click to trigger a handler that calls live_redirect():

# Anti-pattern: handler does nothing but navigate
@event_handler()
def go_to_item(self, item_id, **kwargs):
    self.live_redirect(f"/items/{item_id}/")  # Wasteful round-trip
<!-- Wrong: forces a WebSocket round-trip just to navigate -->
<button dj-click="go_to_item" dj-value-item_id="{{ item.id }}">View</button>

What actually happens:

  1. User clicks button → client sends WebSocket message (50–100ms)
  2. Server receives message, processes handler (10–50ms)
  3. Server responds with live_redirect command (50–100ms)
  4. Client finally navigates to the new view

Total: 110–250ms, plus handler processing time.

Right — using dj-navigate directly:

<!-- Right: client navigates immediately, no server round-trip -->
<a dj-navigate="/items/{{ item.id }}/">View Item</a>

What happens:

  1. User clicks link → client navigates directly

Total: ~10ms (just DOM updates).

Why it matters:

  • Performance: 10–20x faster navigation
  • Network efficiency: saves WebSocket bandwidth
  • User experience: instant response, no loading indicators needed
  • Simplicity: less code, fewer moving parts

When to Use live_redirect() in Handlers

Use handlers for navigation only when navigation depends on server-side logic or validation.

Conditional navigation after form validation:

@event_handler()
def submit_form(self, **kwargs):
    if self.form.is_valid():
        self.form.save()
        self.live_redirect("/success/")  # OK: conditional on validation
    else:
        # Stay on form to show errors
        pass

Navigation based on auth/permissions:

@event_handler()
def view_sensitive_data(self, **kwargs):
    if not self.request.user.has_perm('app.view_sensitive'):
        self.live_redirect("/access-denied/")  # OK: auth check required
        return
    self.show_sensitive = True

Navigation after async operations:

@event_handler()
async def create_and_view_item(self, name, **kwargs):
    item = await Item.objects.acreate(name=name, owner=self.request.user)
    self.live_redirect(f"/items/{item.id}/")  # OK: navigate to newly created item

Multi-step wizard logic:

@event_handler()
def next_step(self, **kwargs):
    if self.current_step == "payment" and not self.payment_valid:
        # Stay on payment step if invalid
        return
    self.current_step = self.get_next_step()
    self.live_patch(params={"step": self.current_step})  # OK: conditional flow

The common theme: the handler does meaningful work before navigating. If your handler only calls live_redirect(), use dj-navigate instead.

Quick Example: Multi-View App

from djust import LiveView
from djust.mixins.navigation import NavigationMixin
from djust.decorators import event_handler

class ProductListView(NavigationMixin, LiveView):
    template_string = """
    <!-- Filter within same view: use dj-patch -->
    <a dj-patch="?category=electronics">Electronics</a>
    <a dj-patch="?category=books">Books</a>

    <div>
        {% for product in products %}
            <!-- Navigate to different view: use dj-navigate -->
            <a dj-navigate="/products/{{ product.id }}/">{{ product.name }}</a>
        {% endfor %}
    </div>
    """

    def mount(self, request, **kwargs):
        self.category = "all"
        self.products = []

    def handle_params(self, params, uri):
        """Called when URL changes via dj-patch or browser back/forward"""
        self.category = params.get("category", "all")
        self.products = Product.objects.filter(category=self.category)

See the Navigation Guide for the complete API reference (live_patch(), live_redirect(), handle_params()).

Developer Tooling

Debug Panel

Interactive debugging tool for LiveView development (DEBUG mode only):

# In settings.py
DEBUG = True  # Debug panel automatically enabled

Open it with Ctrl+Shift+D (Windows/Linux) or Cmd+Shift+D (Mac), or click the floating debug button.

Features:

  • Event handlers — discover all handlers with parameters, types, and descriptions
  • Event history — real-time log with timing metrics (e.g., search • 45.2ms)
  • VDOM patches — monitor DOM updates with sub-millisecond precision
  • Variables — inspect current view state

See the Debug Panel Guide and Event Handler Best Practices.

Event Handlers

Always use the @event_handler decorator for auto-discovery and validation:

from djust.decorators import event_handler

@event_handler()
def search(self, value: str = "", **kwargs):
    """Search handler — description shown in debug panel"""
    self.search_query = value

Parameter convention: use value for form inputs (dj-input, dj-change events):

# Correct — matches what form events send
@event_handler()
def search(self, value: str = "", **kwargs):
    self.search_query = value

# Wrong — won't receive input value
@event_handler()
def search(self, query: str = "", **kwargs):
    self.search_query = query  # Always "" (default)

Architecture

┌─────────────────────────────────────────────┐
│  Browser                                    │
│  ├── client.min.js.gz (~58 KB) — events   │
│  └── WebSocket connection                   │
└─────────────────────────────────────────────┘
           ↕ WebSocket (Binary/JSON)
┌─────────────────────────────────────────────┐
│  Django + Channels (Python)                 │
│  ├── LiveView classes                       │
│  ├── Event handlers                         │
│  └── State management                       │
└─────────────────────────────────────────────┘
           ↕ Python/Rust FFI (PyO3)
┌─────────────────────────────────────────────┐
│  Rust core (native speed)                   │
│  ├── Template engine (<1ms)                │
│  ├── Virtual DOM diffing (<100μs)          │
│  ├── HTML parser                            │
│  └── Binary serialization (MessagePack)    │
└─────────────────────────────────────────────┘

Examples

See the examples/demo_project directory for complete working examples:

  • Counter — simple reactive counter
  • Todo List — CRUD operations with lists
  • Chat — real-time messaging

Run the demo:

cd examples/demo_project
pip install -r requirements.txt
python manage.py migrate
python manage.py runserver

Visit http://localhost:8000.

Development

Project Structure

djust/
├── crates/
│   ├── djust_core/        # Core types & utilities
│   ├── djust_templates/   # Template engine
│   ├── djust_vdom/        # Virtual DOM & diffing
│   ├── djust_components/  # Reusable component library
│   └── djust_live/        # Main PyO3 bindings
├── python/
│   └── djust/             # Python package
│       ├── live_view.py         # LiveView base class
│       ├── component.py         # Component system
│       ├── websocket.py         # WebSocket consumer
│       └── static/
│           └── client.js        # Client runtime
├── branding/                    # Logo and brand assets
├── examples/                    # Example projects
├── benchmarks/                  # Performance benchmarks
└── tests/                       # Tests

Running Tests

# All tests (Python + Rust + JavaScript)
make test

# Individual test suites
make test-python       # Python tests
make test-rust         # Rust tests
make test-js           # JavaScript tests

# Specific tests
pytest tests/unit/test_live_view.py
cargo test --workspace --exclude djust_live

For comprehensive testing documentation, see the Testing Guide.

Building Documentation

cargo doc --open

Roadmap

djust 1.0 is released and stable. Active planning lives in the issue tracker. One notable item still open:

  • React/Vue component compatibility

Security

  • CSRF protection via Django middleware
  • XSS protection via automatic template escaping (the Rust engine escapes all variables by default)
  • HTML-producing filters (urlize, urlizetrunc, unordered_list) handle their own escaping internally; the Rust engine's safe_output_filters whitelist prevents double-escaping, so |safe is never needed with these filters
  • WebSocket authentication via Django sessions
  • WebSocket origin validation and HMAC message signing
  • Per-view and global rate limiting
  • Configurable allowed origins for WebSocket connections
  • View-level auth enforcement (login_required, permission_required) before mount()
  • Handler-level @permission_required for protecting individual event handlers
  • djust_audit command and djust.S005 system check for auth-posture visibility

Report security issues to security@djust.org.

Contributing

Contributions are welcome. Please read CONTRIBUTING.md first.

Areas where help is especially useful:

  • More example applications
  • Performance optimizations
  • Documentation improvements
  • Browser compatibility testing

Supporting djust

djust is open source (MIT licensed) and free. If you use djust in production or want to support development:

  • Star this repository to help others discover it
  • Sponsor on GitHub — from $5/month

License

MIT License — see the LICENSE file for details.

Acknowledgments

Community & Support


Maintained by the djust community.

Release files for djust 1.2.0rc1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for djust 1.2.0rc1
File Size Uploaded
djust-1.2.0rc1.tar.gz 5.9 MB Details

Built distributions (wheels)

Table of built distributions (wheels) for djust 1.2.0rc1
File
djust-1.2.0rc1-cp314-cp314-win_amd64.whl CPython 3.14 CPython 3.14 Windows x86-64 Details
djust-1.2.0rc1-cp314-cp314-manylinux_2_34_x86_64.whl CPython 3.14 CPython 3.14 Linux glibc 2.34+ x86-64 Details
djust-1.2.0rc1-cp314-cp314-macosx_11_0_arm64.whl CPython 3.14 CPython 3.14 macOS 11.0+ ARM64 Details
djust-1.2.0rc1-cp314-cp314-macosx_10_12_x86_64.whl CPython 3.14 CPython 3.14 macOS 10.12+ x86-64 Details
djust-1.2.0rc1-cp313-cp313-win_amd64.whl CPython 3.13 CPython 3.13 Windows x86-64 Details
djust-1.2.0rc1-cp313-cp313-manylinux_2_34_x86_64.whl CPython 3.13 CPython 3.13 Linux glibc 2.34+ x86-64 Details
djust-1.2.0rc1-cp313-cp313-macosx_11_0_arm64.whl CPython 3.13 CPython 3.13 macOS 11.0+ ARM64 Details
djust-1.2.0rc1-cp313-cp313-macosx_10_12_x86_64.whl CPython 3.13 CPython 3.13 macOS 10.12+ x86-64 Details
djust-1.2.0rc1-cp312-cp312-win_amd64.whl CPython 3.12 CPython 3.12 Windows x86-64 Details
djust-1.2.0rc1-cp312-cp312-manylinux_2_34_x86_64.whl CPython 3.12 CPython 3.12 Linux glibc 2.34+ x86-64 Details
djust-1.2.0rc1-cp312-cp312-macosx_11_0_arm64.whl CPython 3.12 CPython 3.12 macOS 11.0+ ARM64 Details
djust-1.2.0rc1-cp312-cp312-macosx_10_12_x86_64.whl CPython 3.12 CPython 3.12 macOS 10.12+ x86-64 Details
djust-1.2.0rc1-cp311-cp311-win_amd64.whl CPython 3.11 CPython 3.11 Windows x86-64 Details
djust-1.2.0rc1-cp311-cp311-manylinux_2_34_x86_64.whl CPython 3.11 CPython 3.11 Linux glibc 2.34+ x86-64 Details
djust-1.2.0rc1-cp311-cp311-macosx_11_0_arm64.whl CPython 3.11 CPython 3.11 macOS 11.0+ ARM64 Details
djust-1.2.0rc1-cp311-cp311-macosx_10_12_x86_64.whl CPython 3.11 CPython 3.11 macOS 10.12+ x86-64 Details
djust-1.2.0rc1-cp310-cp310-manylinux_2_34_x86_64.whl CPython 3.10 CPython 3.10 Linux glibc 2.34+ x86-64 Details

Total release size: 149.6 MB

Release files / djust-1.2.0rc1.tar.gz

Download URL djust-1.2.0rc1.tar.gz
Size 5.9 MB
Tags Source
SHA-256 checksum
How to use checksums
efefda280ad95e930827001eb7e504312e70659917df8967d81f59b3c9106555
BLAKE2b-256 checksum
How to use checksums
a422414b5dadbe8a4c5876c67f59f077e2c643e969b638c579693d5c435d05a5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp314-cp314-win_amd64.whl

Download URL djust-1.2.0rc1-cp314-cp314-win_amd64.whl
Size 8.6 MB
Tags CPython 3.14 Windows x86-64
SHA-256 checksum
How to use checksums
2c87b4c981216cbbd2d3dc1e9bc125bddeaf307efdea6629b917416262525b93
BLAKE2b-256 checksum
How to use checksums
88d910cbd0dc768f9343e535b28c7d040133bc3e7ab014f286ce12aa60a723dc
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp314-cp314-manylinux_2_34_x86_64.whl

Download URL djust-1.2.0rc1-cp314-cp314-manylinux_2_34_x86_64.whl
Size 8.6 MB
Tags CPython 3.14 Linux glibc 2.34+ x86-64
SHA-256 checksum
How to use checksums
b09928ffce8ed15f5b01810acdcf5c6602a42aeebd5b8d8c6473877c93d7fa7a
BLAKE2b-256 checksum
How to use checksums
8f9fa49535d2119be7a0807bd377d606a5ae3eea62720dfba9fc248ae2535c24
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp314-cp314-macosx_11_0_arm64.whl

Download URL djust-1.2.0rc1-cp314-cp314-macosx_11_0_arm64.whl
Size 8.2 MB
Tags CPython 3.14 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
07cf7d585eac7e0a5d49dc2ad720dc54896d5b91caebbb22bc2a942cda6dc9fd
BLAKE2b-256 checksum
How to use checksums
922a2cd4337fb4ab3fa9e5bfe9cfbd5acb95485d3d12c60ace8317f347cf6954
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp314-cp314-macosx_10_12_x86_64.whl

Download URL djust-1.2.0rc1-cp314-cp314-macosx_10_12_x86_64.whl
Size 8.4 MB
Tags CPython 3.14 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
37f0c216cff1e2741508e23708dc2c8c0f8e24042b59cc3607e2f169c6b2dbcf
BLAKE2b-256 checksum
How to use checksums
0a267e126004a0b9c3f9064233cceb821a1752aa1cbb36b2ac7140e0c247ff07
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp313-cp313-win_amd64.whl

Download URL djust-1.2.0rc1-cp313-cp313-win_amd64.whl
Size 8.6 MB
Tags CPython 3.13 Windows x86-64
SHA-256 checksum
How to use checksums
550c28540bec3cd423a1815a0eaca194a3cc42a7f4e16bab9e404105317897f4
BLAKE2b-256 checksum
How to use checksums
9964756a5186cc3e7b3d3c3fcea51debe79888fcbec3858f6207125249ae73a2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp313-cp313-manylinux_2_34_x86_64.whl

Download URL djust-1.2.0rc1-cp313-cp313-manylinux_2_34_x86_64.whl
Size 8.6 MB
Tags CPython 3.13 Linux glibc 2.34+ x86-64
SHA-256 checksum
How to use checksums
293fd505a95451cb267fc04cdcec5fe1320c55efeb028da4b48588601efeeb05
BLAKE2b-256 checksum
How to use checksums
34754645351784f43a7225e5bfaddee042ab20fff59b29475ea145bbbbb7858a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp313-cp313-macosx_11_0_arm64.whl

Download URL djust-1.2.0rc1-cp313-cp313-macosx_11_0_arm64.whl
Size 8.2 MB
Tags CPython 3.13 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
d58009cae65dd403689c8adfc175ac61b97a640b0080178038386850cff69309
BLAKE2b-256 checksum
How to use checksums
87e8a671cd5988e29a6c15283b32af9f95d305e12e9219f53ba84c98edbd25e5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp313-cp313-macosx_10_12_x86_64.whl

Download URL djust-1.2.0rc1-cp313-cp313-macosx_10_12_x86_64.whl
Size 8.4 MB
Tags CPython 3.13 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
a8391c7db5222c9c91d2d22b8a006e617e5364a1332854d96aa2d1249898826d
BLAKE2b-256 checksum
How to use checksums
d09adb62bbd0f7f2c08fb3d90935aaee85bf7bb041ca7679fee374b8fae0a6d4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp312-cp312-win_amd64.whl

Download URL djust-1.2.0rc1-cp312-cp312-win_amd64.whl
Size 8.6 MB
Tags CPython 3.12 Windows x86-64
SHA-256 checksum
How to use checksums
b0e75d3a4c217113819652f0ca56e8668180a1af098293363a18df6c38d97f62
BLAKE2b-256 checksum
How to use checksums
0f2dabe503c968c4601f3fa05c96f39b5b7310f9b83f0f798a573ee145480176
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp312-cp312-manylinux_2_34_x86_64.whl

Download URL djust-1.2.0rc1-cp312-cp312-manylinux_2_34_x86_64.whl
Size 8.6 MB
Tags CPython 3.12 Linux glibc 2.34+ x86-64
SHA-256 checksum
How to use checksums
47c13b507be847b06d3ce769c6f6ef7576d2e9d102974c897ad912a8d2adbf33
BLAKE2b-256 checksum
How to use checksums
2e04a7e5f32053d1b118a2575ee41694bde4c078a14867207ae239d49c9150e2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp312-cp312-macosx_11_0_arm64.whl

Download URL djust-1.2.0rc1-cp312-cp312-macosx_11_0_arm64.whl
Size 8.2 MB
Tags CPython 3.12 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
98eb2209139fe58060a0ee3ee02e79205d297703a438f6c0e9a1b3725301a4c5
BLAKE2b-256 checksum
How to use checksums
81c1e3a06b806c602dc13c4ad56c058c9e697610551a26c126b2e35ec705971b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp312-cp312-macosx_10_12_x86_64.whl

Download URL djust-1.2.0rc1-cp312-cp312-macosx_10_12_x86_64.whl
Size 8.4 MB
Tags CPython 3.12 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
c1cadc968f812320f71e1ed92b4d1342f228d013f8d4e7f50209f22c3cf3305e
BLAKE2b-256 checksum
How to use checksums
f3797509317757bc1ea61f3ac9c31018d02acf0ceb89e8acfaa3b145bf449437
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp311-cp311-win_amd64.whl

Download URL djust-1.2.0rc1-cp311-cp311-win_amd64.whl
Size 8.6 MB
Tags CPython 3.11 Windows x86-64
SHA-256 checksum
How to use checksums
bd5a78be0f2601f7af62a7a620aeff7c31d5e3c8457787229246129f0d94d80c
BLAKE2b-256 checksum
How to use checksums
0f8e653e20a902e8cc3cca8b03733ecff466ab6a1dbf31c0098fa6a64336ec7f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp311-cp311-manylinux_2_34_x86_64.whl

Download URL djust-1.2.0rc1-cp311-cp311-manylinux_2_34_x86_64.whl
Size 8.5 MB
Tags CPython 3.11 Linux glibc 2.34+ x86-64
SHA-256 checksum
How to use checksums
24d07e2f946647e39cd6a537a29ec5968e4655ee52a69f8718527d8a00bfede1
BLAKE2b-256 checksum
How to use checksums
928be0d26aaab52f27bcb040e1c9b0fd6c2a5088c61f5778d61cc921327bc3b2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp311-cp311-macosx_11_0_arm64.whl

Download URL djust-1.2.0rc1-cp311-cp311-macosx_11_0_arm64.whl
Size 8.3 MB
Tags CPython 3.11 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
91fabcefdc612bc580394bd8b55192905967c725ebba7a3ed9c6e509ea12c50c
BLAKE2b-256 checksum
How to use checksums
57351d09fb5dd1fc046924b262e038ab5d7e85074ca65c08009a5e9082bc9a43
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp311-cp311-macosx_10_12_x86_64.whl

Download URL djust-1.2.0rc1-cp311-cp311-macosx_10_12_x86_64.whl
Size 8.4 MB
Tags CPython 3.11 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
481b0df827b7c3046fc611c00d6cd3042f9fe312ad7a09007728b80b90fb9696
BLAKE2b-256 checksum
How to use checksums
9fc2e107dad4305abee741f7a114b252ef93f98fcfb361ed157a281a2289676e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release files / djust-1.2.0rc1-cp310-cp310-manylinux_2_34_x86_64.whl

Download URL djust-1.2.0rc1-cp310-cp310-manylinux_2_34_x86_64.whl
Size 8.5 MB
Tags CPython 3.10 Linux glibc 2.34+ x86-64
SHA-256 checksum
How to use checksums
35d30daaa752749da0df383f4b1e98312c11afd270a69bf2c1f8075e1d16cdc6
BLAKE2b-256 checksum
How to use checksums
8dd3c9bfb455c298506b3299f47570d49ecb76841af572043a624cfcaf4053e0
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 1, 2026.

Transparency log

Release history Release notifications | RSS feed

1.2.0

18 release files

This release

1.2.0rc1 This release

18 release files

1.1.4

18 release files

1.1.3

18 release files

1.1.2

18 release files

1.1.1

18 release files

1.1.0

18 release files

1.0.8

18 release files

1.0.7

18 release files

1.0.6

18 release files

1.0.5

18 release files

1.0.4

18 release files

0.9.7

18 release files

0.9.6

18 release files

0.9.1

18 release files

0.9.0

18 release files

0.4.4

11 release files

0.4.3

11 release files

0.4.2

24 release files

0.4.1

11 release files

0.4.0

11 release files

0.3.8

11 release files

0.3.7

11 release files

0.3.6

11 release files

0.3.4

11 release files

0.3.2

11 release files

0.3.1

11 release files

0.3.0

11 release files

0.2.1

20 release files

0.2.0

20 release files

0.1.9

11 release files

0.1.8

14 release files

0.1.7

14 release files

0.1.6

14 release files

0.1.5

14 release files

0.1.4

14 release files

0.1.3

14 release files

0.1.2

13 release files

0.1.0

3 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page