Frequently Asked Questions

djust is a hybrid Python/Rust framework that brings Phoenix LiveView-style reactive server-side rendering to Django. It allows you to build real-time, interactive web applications using only Python—no JavaScript required. The Rust VDOM engine provides blazing-fast rendering (0.8ms) and sub-millisecond diffing (<100μs).

No! djust provides a 100% Python API. Rust is only used internally for the VDOM engine and template rendering. You write all your code in Python, just like regular Django. The Rust components are pre-compiled and distributed via pip.

Simply run pip install djust. This will install djust and all dependencies including Django and Channels. Then follow our Quick Start guide to build your first app in 5 minutes.

Absolutely! djust is designed to work alongside traditional Django views. You can incrementally adopt it—start with one interactive page, then add more. It works with existing Django models, forms, authentication, and middleware.

Yes, but you usually won't need DRF with djust. djust replaces REST APIs for your frontend—business logic runs on the server and you send minimal VDOM patches instead of JSON. Keep DRF for mobile apps or third-party integrations.

Yes! djust has built-in framework adapters for Bootstrap 5, Tailwind, and plain HTML. Set css_framework='bootstrap5' or 'tailwind' in settings. Django Forms automatically render with framework-specific classes.

Yes! djust's architecture is inherently more secure than traditional SPAs: (1) Zero API attack surface—no REST/GraphQL endpoints to exploit, (2) Server-side business logic—pricing, validation, authorization stays hidden, (3) CSRF protection—built-in Django CSRF, (4) XSS prevention—automatic HTML escaping. See our security page.

Check the documentation, browse GitHub issues, or open a new issue. We actively monitor and respond to community questions.

djust uses a hybrid Python-Rust approach. State lives in a Rust struct (for performance) but is managed through Python. Your LiveView class holds a reference to a Rust backend that handles VDOM diffing and rendering. State is serialized using MessagePack (5-10x faster than pickle, 30-40% smaller than JSON) with optional zstd compression.

One LiveView per page (recommended pattern). If you have 10 users viewing a page, you'd have ~10 LiveView instances. Components within that LiveView share the parent's state—they don't spawn separate server instances or WebSocket connections. Memory footprint per instance is small (just your state variables).

Yes! The in-memory backend uses RLock for thread-safe access, suitable for development and single-server deployments. For horizontal scaling, use the Redis backend—any server can deserialize and serve any session, no sticky sessions required.

When the WebSocket connection closes (user navigates away, closes tab, or TTL expires), the state is garbage collected. With Redis, TTL-based expiration handles cleanup automatically. You can configure SESSION_TTL in settings (default: 1 hour).

Three honest tradeoffs: (1) Server memory scales with concurrent users—each connected user consumes server memory (fine for most apps). (2) Latency-sensitive interactions—every action round-trips to the server (we optimize heavily, but never as fast as pure client-side). (3) Still in alpha—the framework works but you may hit edge cases. What becomes easier: everything else! Forms, CRUD, dashboards, real-time updates become significantly simpler.

Very latency-sensitive UIs like games or real-time drawing apps. For offline-first web apps, you'd need additional client-side storage. However, djust works well in Electron for offline-capable desktop apps since the server runs locally.

Yes! djust's architecture works surprisingly well for Electron apps. Since all logic is server-side, you run the Django server on localhost. The user experience is native, and you get offline support automatically because the server is local.

djust brings LiveView concepts to Django/Python. Key differences: (1) Rust VDOM engine is faster than Elixir's (~40% faster diffing), (2) smaller client bundle (~5KB vs ~30KB), (3) Python instead of Elixir/functional programming, (4) Django ORM integration. Choose djust if you're already using Django or prefer Python.

djust is 10x faster (Rust vs PHP rendering), has a 10x smaller bundle (~5KB vs ~50KB), and supports real-time WebSocket updates (not just HTTP polling). Both offer similar developer experience, but djust provides better performance and real-time capabilities. See our detailed comparison.

HTMX is framework-agnostic and simpler, but requires more manual wiring. djust provides stateful components, automatic VDOM diffing, real-time WebSocket updates, and Django Forms integration. Choose djust for complex interactive UIs, HTMX for simpler server-driven pages.

Many Python-only reactive frameworks struggle with scaling—they use plain in-memory objects that can't scale across threads without sticky load balancer configuration. djust was designed with scaling in mind: thread-safe state management, full serialization support (MessagePack + optional compression), and Redis backend for horizontal scaling.

Three reasons: (1) Rust VDOM engine—template rendering in 0.8ms, diffing in <100μs, (2) Minimal client JavaScript—only ~5KB to download, (3) Fingerprinting and optimized diffing—skip unchanged sections entirely. We're striving for minimal latency to make the difference from SPAs imperceptible for typical interactions.

10,000+ concurrent WebSocket connections per server (4 cores, 8GB RAM). Memory usage is ~2.5 KB per connection thanks to Rust's efficient VDOM storage. For higher scale, use Redis backend for horizontal scaling across multiple servers.

Yes! Components below the fold don't establish WebSocket connections until scrolled into view. This can reduce memory usage by 20-40% on pages with many components.

Deploy like any Django app, but use an ASGI server (uvicorn, daphne, hypercorn) instead of WSGI. Example: uvicorn myproject.asgi:application --host 0.0.0.0 --port 8000. Works on Heroku, AWS, Google Cloud, DigitalOcean, Railway, etc. See our deployment guide for platform-specific instructions.

WebSockets are optional! You can configure djust to use HTTP-only mode with use_websocket=False in settings. HTTP mode works like Livewire (polling), but you lose real-time push updates. Recommended: use WebSockets for best UX.

Use the Redis state backend in settings. This allows multiple servers to share session state—any server can pick up any user's session. No sticky sessions required. Configure with STATE_BACKEND='redis', REDIS_URL, SESSION_TTL, and optionally COMPRESSION_ENABLED.

Common causes: (1) Nginx/load balancer not configured for WebSockets (add proxy_http_version 1.1 and upgrade headers), (2) session timeout too short (increase SESSION_TTL), (3) firewall blocking WebSocket traffic. Check browser console for error messages.

Yes! djust is MIT-licensed open source, free forever for any use including commercial projects.