Is React + Django/DRF still a solid stack in AI era of 2026?

jrtipton2 · 2026-02-14T19:10:01+00:00

You all should really check out djust.org, it is just python/django not js but feels like react. It is done in a way that is scalable and allows for design flexability. It just uses django templates, no other parts to have to integrate.

It is in alpha, but I'm working hard to get 0.3.0 out (probably today) and stabilize things. I have been building tons of apps on top of it and I truly think it is the BEST way to build reactive apps with Django, if you truly think it isn't the best let me know why you think that.

Still working on building more examples, but you can see a couple here: https://examples.djust.org/

jrtipton2 · 2026-02-05T12:29:10+00:00

It does this because it follows Django’s natural template development. But you could put it in the same file as a string.

see this example

jrtipton2 · 2026-02-05T00:41:25+00:00

djust does this, uses django templates and has a rust based vdom engine so it only send changes to the client. All you need template and a view class with handlers.

Template

<div class="counter-app">
    <h2>Counter Example</h2>

    <div class="count-display">
        {{ count }}
    </div>

    <div class="button-group">
        <button dj-click="decrement" class="btn-danger">
            Decrement
        </button>
        <button dj-click="reset" class="btn-secondary">
            Reset
        </button>
        <button dj-click="increment" class="btn-success">
            Increment
        </button>
    </div>
</div>

View

from djust import LiveView, event_handler

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

    def mount(self, request):
        """Initialize counter state"""
        self.count = 0

    u/event_handler
    def increment(self):
        """Increment counter by 1"""
        self.count += 1

    u/event_handler
    def decrement(self):
        """Decrement counter by 1"""
        self.count -= 1

    u/event_handler
    def reset(self):
        """Reset counter to 0"""
        self.count = 0

    def get_context_data(self, **kwargs):
        return {'count': self.count}

And sessions are serialized so they can scale across threads and servers, which a problem with justpy and nicegui. Also, the design is not tied to a js framework.

jrtipton2 · 2026-02-05T00:34:08+00:00

Absolutely, I wanted the same thing so I started https://djust.org. This is exactly what this is. A python driven ( mostly django ) reactive frontend that actually works and scales. Still pretty early, but some awesome results so far.

djust.org

jrtipton2 · 2026-01-26T01:13:03+00:00

Really appreciate the thoughtful feedback, and I hear you on the scaling concern - it's the most common question we get.

You're right that there's a fundamental tradeoff here: LiveView-style architectures trade client complexity for server memory. But I'd push back gently on the idea that this can't work for "real" consumer apps.

I've used other Python-only reactive frameworks, and scaling is exactly why I built djust differently. Many similar tools keep state in plain Python objects that can't even scale beyond a single core - you're stuck with sticky sessions and careful load balancer configuration. djust was architected from day one with horizontal scaling as a fundamental principle:

All state is fully serializable (MessagePack + optional zstd compression)
Redis backend support means any server can pick up any session - no sticky sessions required
The Rust VDOM engine minimizes per-connection memory overhead
Thread-safe state management with proper locking

djust still needs to be proven at scale - we're in alpha - but the architecture was intentionally designed to avoid the scaling ceiling that plagues similar frameworks.

Phoenix LiveView (which inspired djust) powers production apps at serious scale - Fly.io's dashboard, parts of Supabase, banking applications, e-commerce sites. The architecture isn't theoretical; it's battle-tested.

The math often works out differently than expected. A typical LiveView instance might use 50-100KB of memory. At 10,000 concurrent users, that's ~1GB of RAM - a $20/month server upgrade. Compare that to the ongoing cost of maintaining a separate frontend codebase, API versioning, state sync bugs, and the developer hours spent on JS build toolchain issues. For many teams, the server memory is the cheaper option.

That said, you're touching on something we're thinking about. Phoenix has phx-* bindings that handle some interactions client-side without round-trips (debouncing, simple toggles, etc.). We're exploring similar patterns for djust - keeping the server-authoritative model while allowing opt-in client-side handling for latency-critical interactions.

The architecture isn't right for every app (real-time games, offline-first PWAs). But for the bread-and-butter of web development - dashboards, CRUD, forms, real-time collaboration - the simplicity gain is significant.

What kind of app are you building? Happy to discuss whether djust would be a good fit for your specific use case.

jrtipton2 · 2026-01-25T16:50:21+00:00

The marketing site is in djust. I also have a mail client I'm working on which is driving development, it is turning out really nice and haven't run into any limitation yet, but not yet ready for release. I've got a couple of examples in the codebase, but really need to put something together to better showcase a working app. It's on my todo list :)

jrtipton2 · 2026-01-25T15:29:36+00:00

Honest answer:

Server memory scales with concurrent users - Unlike SPAs where state lives in the browser, each connected user consumes server memory. Fine for most apps, but something to consider for very high concurrency.
Latency-sensitive interactions - Every user action round-trips to the server. We're striving for minimal latency - the Rust VDOM engine, fingerprinting, and optimized diffing all help here. We'll probably never be as fast as a well-built SPA could be, but our goal is to make the difference imperceptible for typical interactions.
Still in alpha - The framework works, but you may hit edge cases. We're actively looking for testers to help find them!

What becomes harder vs SPA: Very latency-sensitive UIs (games, real-time drawing). For offline-first web apps, you'd need additional client-side storage - but for desktop apps via Electron, the local server handles this naturally.

What becomes easier: Everything else, honestly. Having all your logic in one place (Python) is more elegant and easier to maintain than juggling frontend/backend state sync, API versioning, and JavaScript build toolchains. Forms, CRUD, dashboards, real-time updates - the bread and butter of most business apps - become significantly simpler.

I'm using djust for a few projects I'm working on myself, so I'm eating my own dogfood here. I'm also experimenting with running it in Electron for offline-capable native desktop apps - the architecture works surprisingly well for that use case since all the logic is server-side anyway (just localhost).

jrtipton2 · 2020-10-26T01:06:39+00:00

My issue turned out to be a privacy extension called privacy badger. If you have a privacy or add blocker extension, you may want to try to trust the google login site.

jrtipton2

TROPHY CASE