Jose Responds To Elixir LiveView Not Good Enough

The central fight is over what counts as a “ceiling” for server-driven UI—especially Phoenix LiveView—and whether using client-side DOM libraries (like sortable drag-and-drop) undermines LiveView’s real-time promise. Jose Valim, creator of Elixir and the LiveView ecosystem, argues that modern web apps inevitably juggle both server state and client state, and that real-time UX only works when the framework treats those states as first-class concerns rather than pretending one side can be ignored.

The dispute starts with a long tweet thread claiming LiveView is “not good enough,” with examples of apps being “broken in seconds” and complaints that LiveView’s approach can be janky or fragile. The counterpoint is that LiveView’s model is designed for rich interactivity while keeping server-rendered HTML and real-time updates coordinated. In practice, the conversation narrows to a specific claim: if a UI interaction relies on external client-side DOM manipulation (for instance, drag-and-drop via SortableJS), that shouldn’t automatically be treated as a failure of LiveView. Instead, it can be the exact kind of “client-side behavior” LiveView is meant to support through integration points.

Jose’s article reframes the whole argument around state synchronization. Web pages can become stale immediately after render because other actors may change the underlying data—new comments, updated availability, or a user clicking “buy” before the server confirms success. That same mismatch appears even when only one user is involved: optimistic UI can show a “success” state that later gets corrected, and collaborative editing can create merge conflicts when multiple users change overlapping fields. The core message is that client-side state (even if it’s just input text) exists whether or not a framework encourages it, and large “client caches” that must stay in sync are a common source of bugs.

From there, the article defines “real time” as the server sending updates on a short cadence (seconds, not minutes) and stresses that real-time doesn’t mean blindly overriding what the user is doing. A collaborative editor might synchronize text instantly, but a category dropdown changing out from under a user can feel jarring unless the UI communicates what changed and why. LiveView’s approach is to keep a long-lived connection (a websocket “long pole”) and to control how updates are propagated and rendered so they remain cheap and performant.

To handle the tricky gap between what the client does immediately and what the server confirms later, LiveView uses an internal clock/sequence mechanism. When events are pushed to the server, LiveView tags updates with an always-increasing identifier; the client queues or applies server responses only when they match the most recent identifier, preventing “rollback” from older debounced events after a user submits. Jose positions this as a practical solution to a classic problem: inflight requests and out-of-order responses can otherwise undo UI state.

The discussion ends by broadening the lens: LiveView isn’t trying to eliminate JavaScript entirely, but to reduce the amount of custom client glue needed for production-grade real-time apps. Offline mode is acknowledged as a limitation, and the conversation also touches on performance tradeoffs (server-rendered HTML vs JSON) as context-dependent. The takeaway is less about winning a framework purity contest and more about whether the stack enables complex, multi-user, near-real-time experiences with fewer moving parts and fewer synchronization bugs.