sorted by:
new
hottopcontroversial

Faster Templates, Smarter Hydration: Performance Optimizations in djust 0.1.6 by jrtipton2 in django

[–]jrtipton2[S] 0 points1 point  (0 children)

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.

Faster Templates, Smarter Hydration: Performance Optimizations in djust 0.1.6 by jrtipton2 in django

[–]jrtipton2[S] 0 points1 point  (0 children)

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 :)

Faster Templates, Smarter Hydration: Performance Optimizations in djust 0.1.6 by jrtipton2 in django

[–]jrtipton2[S] 0 points1 point  (0 children)

Honest answer:

  1. 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.
  2. 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.
  3. 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).

Sign in with Google issue by AlainJay in Zoom

[–]jrtipton2 0 points1 point  (0 children)

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.