Why djust works
the way it does

These are the decisions behind djust and the reasons for them. We update this page as the framework evolves.

I

Complexity Is the Enemy

Every layer in a stack can break, and someone has to learn it. djust tries to have fewer layers.

A typical web app today has a bundler, a transpiler, a client router, a state store and an API serializer. Each one is reasonable on its own. Together they take a lot of time to maintain.

djust leaves most of them out. Your project has no build step and no node_modules. State lives on the server, so there is nothing to keep in sync with the browser. You write Python and HTML and deploy them.

  • One prebuilt client file, about 65 KB gzipped
  • No npm packages in your project
  • No bundler or build step in your project
  • Deploys with pip install and an ASGI server such as uvicorn
II

Developer First

WebSockets, diffing and reconnection are the framework's job. Your code should be about your app. When something goes wrong, the error should say what happened and how to fix it.

Adding live updates to a normal Django app usually means picking a WebSocket library, wiring up pub/sub, writing reconnect logic, and then building the client half. That is weeks of work before any product code.

In djust most of that is a mixin or a function call. System checks run at startup and catch configuration mistakes before your users run into them.

  • PresenceMixin tracks who's online
  • stream_text() streams LLM tokens or logs to the browser
  • push_to_view() updates open pages from a Celery task or a signal
  • dj-model binds a form input to a view attribute
  • System checks like T018 and C016 flag mistakes when the server starts
III

AI-Ready by Design

AI-generated code is safer when there is less of it. djust keeps transport, live-connection auth and state handling inside the framework, so generated code is mostly views and templates.

In a typical SPA stack, a model writes React components, API endpoints, auth flows, validation and CORS config. Each has its own conventions and security assumptions.

With djust there is no API layer to generate and no client-side auth to set up. Those parts live in the framework, where they are tested and maintained in one place, and every improvement reaches every app with pip install --upgrade.

  • No API endpoints to generate, so no CORS, serializers or auth tokens
  • Security fixes land in the framework, not in each app
  • One pattern for views, components and event handlers
IV

One Stack, One Truth

A typical app is a backend, an API and a frontend: three codebases for one product. djust keeps it in one Python codebase.

In the usual setup every feature touches all three, each with its own language, tests and deploys. Bugs collect at the boundaries.

In djust the view renders HTML on the server and sends updates over a WebSocket. There is no REST contract to version and no TypeScript type that can drift from your Django model. When something breaks, the stack trace is in one language.

  • No API layer between your views and the page
  • Python from the database to the browser update
  • One deploy, with no frontend release to coordinate
  • One language to debug in
V

Performance Is Architecture

Rendering runs on every event, so djust renders templates and diffs pages in Rust. Your code stays in Python.

A LiveView re-renders on every click and keystroke. djust renders your Django templates in Rust, diffs the result against the previous render, and sends only the changes.

With an empty context, the Rust engine renders about 5.7x faster than Django's. With real view state, the median across our benchmark is about Django's speed, and around 2x on loop-heavy templates. The bigger saving is on the wire: after each event only the changed parts of the page are sent.

  • 98.6% of Django's own template tests pass on the Rust engine
  • Render cost follows what the template reads, not the size of the view state
  • Only changed DOM nodes are sent after each event
  • Python for your logic, Rust for the framework's inner loop
VI

Own Your Stack

You should be able to read and change the client code your framework ships. You should not have to depend on a package registry you do not control.

npm install pulls in hundreds of transitive packages, and any of them can be compromised or abandoned. It has happened several times.

djust's client is plain JavaScript that ships inside the Python package. Your project has no node_modules, and nothing loads from a CDN. If you need to change how the client behaves, the unminified source is right there in the wheel.

  • Unminified client.js ships next to the minified build
  • No npm, webpack or node_modules in your project
  • Nothing loaded from a CDN
  • MIT licensed
VII

Opinionated Where It Matters, Flexible Where It Doesn't

djust has firm opinions about security, state, transport and rendering, and none about your markup or CSS.

When there is one way to do the risky things, teams don't have to agree on one, and AI tools get them right more consistently.

Your UI is yours. djust renders whatever HTML you write, styled with Tailwind, Bootstrap or plain CSS. The component library and theme packs are optional. Use them, or write every tag yourself.

  • Fixed conventions for security, state and transport
  • One pattern that AI tools can learn and repeat
  • No CSS framework required
  • Components and themes you can use or ignore

Try it

The quickstart takes a few minutes. You can also open start.djust.org in two tabs and watch them sync.

Get Started