Yes JS in some cases can actually do things in lockstep. But I do remember all the aweful input mask javascript code of the past, which was not at all better in breaking peoples ability to properly write in an input field.
Personally I consider the other direction a much more useful one. All those tools deal with similar complexities, just under different latency and access to optimizations. As soon as you do anything async in js you’re back to “no longer in lockstep” anyways.
I see where you’re coming from here, but this is strictly an interface design problem and orthogonal to the topic of controlled components.
Allowing the framework (JS or not) to take complete control of the state is necessary to build complex interfaces. As a simple example, we discussed default values and form resets above, but for a complex UI you would probably want to implement those things yourself with specific business logic. I.e. which inputs are reset, to what values, how do they interact with each other? Etc.
There was a thread on here the other day where somebody had a form with two inputs that updated each other and they were having trouble making that work with LiveView. I didn’t reply because I actually cannot think of a way to do that properly in LV. You literally have to write a hook.
This doesn’t mean you can’t provide a framework with useful guarantees. Post-fiber React, for example, is asynchronous under the hood (to avoid blocking the render thread too long) but the engine is still carefully designed not to tear the UI when updating and to execute updates in the proper order.
Analogously, a well-designed distributed database can still offer strict serializability (Spanner, FDB) even if there are many poorly designed databases which do not (every single Spanner derivative for some reason).
You don’t need to write a hook. You can still go the route of “my framework controls the input” by forcing an update to the ID of the input, which makes morphdom consider the input a new one and force overwriting the input text. If that’s a good idea is a different question though and that’s where a hook becomes interesting again.
And that’s exactly where e.g. electric-closure comes in and compiles applications not just for the client, but the combo of client and server – extending the underlying ideas to work across the network gap. Latency won’t go away, but it doesn’t mean ideas cannot extend beyond the latency. In the end it doesn’t matter if you get 60ms of latency because you’re on a cheap old android or because you’re talking to the next datacenter.
The particular case was a bit trickier than that. And, ahem, you were the one to suggest a hook 
But the underlying problem there is a consistency problem: the state the client receives back from the server is out of date (user has typed more) since it was sent. The bit about debouncing is actually a red herring.
This framework came up before in another similar discussion (it might have even been me who brought it up, I can’t recall) but I still haven’t taken a proper look yet. I really need to do so, it sounds very interesting.
BTW, for anyone trying to search it’s Electric Clojure.
Cool, thanks for sharing the link. Looks like it has some similarities to the approach Hologram is taking though maybe pushed to another level with its client and server blocks in the same function and its DOM approach. Also reminds me a bit of Meteor’s isomorphism.
FWIW I would characterize this as an instance of “client-side local state reconciliation”. I think “reconciliation” is a better term than synchronization in this domain as the former is associated with network boundaries and netsplits, which is different from what the Hologram user’s experience is (Hologram owns the network hop for you, then does reconciliation between the new client-local state and the existing DOM-owned client-local state, if I understand things correctly).
Hologram transpiles your Elixir UI components to JavaScript that runs entirely in the browser. When you write:
<input type="text" value={@age} $change="update_age" />
def action(:update_age, %{event: %{value: age}}, component) do
put_state(component, age: age)
end
This becomes JavaScript that executes locally in the browser. So when a user types:
The “same execution context” means both the DOM manipulation and your Elixir state management logic are running as JavaScript in the browser, so there’s no distributed system to coordinate. No server roundtrips, no network latency, no consistency gaps.
You still have a server for your backend logic, but here’s the key: Hologram automatically determines what needs to run on the client (UI components, event handlers, state management) and transpiles only that code to JavaScript. Your database queries, business logic, etc. stay on the server as regular Elixir.
So you write everything in Elixir, and Hologram figures out the client/server boundary for you - transpiling just the UI parts to JS while keeping the rest as server-side Elixir.
Looking at this discussion, I think there’s an important distinction to make about scope and intended use cases that clarifies the architectural differences.
You’re right that Hologram is still a separate stateful system next to the DOM, and that external DOM manipulation (browser plugins, console commands) can create inconsistencies that won’t be corrected until the next reconciliation cycle. That’s a fair technical critique for specific cases that intentionally avoid the intended use through the API.
However, I’d argue this is similar to saying “Linux isn’t secure because you can modify /dev/mem as root” - while technically true, it misses the practical scope of what the system is designed to solve.
For user-driven interactions - which represent 99.9% of real web app usage - Hologram genuinely does prevent inconsistencies rather than just correct them:
<input $change="update_name" value={@name} />
def action(:update_name, %{event: %{value: name}}, component) do
put_state(component, :name, name)
end
This creates a closed synchronous loop:
JavaScript’s event loop guarantees that the event handler runs atomically and completely before any other queued tasks can execute. This means the DOM event processing and state update happen in true lock-step, with no inconsistency window where they can diverge.
The fundamental issue is that latency creates an unavoidable distributed systems challenge for LiveView:
Interestingly, even direct input manipulation demonstrates Hologram’s robustness: if someone does document.getElementById("my-input").value = "hacked" and the input has a $change event handler connected to the state, Hologram reconciles automatically and immediately when the programmatic change occurs.
Yes, someone could do document.getElementById("my-div").innerHTML = "hacked content" as you mentioned and break VDOM synchronization until the next reconciliation cycle - but this is equivalent to:
dangerouslySetInnerHTML in React and complaining about inconsistenciesThese break the intended API contract and represent edge cases, not fundamental architectural limitations.
For the scenarios developers actually encounter (form interactions, user events, programmatic state updates through the framework), Hologram’s architecture eliminates the consistency problems that LiveView cannot solve due to network latency.
While no abstraction is perfect when you deliberately bypass it, the practical advantage for intended use cases is significant - as @garrison noted with his example of two-input forms that “literally require hooks” in LiveView but work naturally in Hologram.
When developers use Hologram’s event system as intended, it prevents inconsistencies from occurring. When they bypass this system with direct DOM manipulation, inconsistencies can happen - but that’s breaking the API contract.
So… to sum up… given that DOM event handlers are guaranteed to execute atomically without interruption from other queued JavaScript, I think it’s fair to say the distinction I made earlier that you quoted holds true within the framework’s intended scope of user-driven interactions.
Thanks for bringing up Electric Clojure! I took some time to look at the project, and it’s definitely a fascinating approach.
I can see many conceptual similarities with Hologram - particularly around providing a unified developer experience across the stack and writing in one language while automatically splitting code for client vs server execution.
When I started working on Hologram over 5 years ago, I actually considered a similar network-transparent approach where client and server code could be more seamlessly intertwined. However, I ultimately decided against it for several reasons:
Thinking about this now with more experience developing Hologram, I can see how that initial instinct about boundary awareness translates into specific technical concerns related to Electric Clojure’s approach:
That said, I find Electric Clojure’s approach very interesting and innovative! It’s exploring a different point in the design space, and there may be elegant solutions to these challenges that I haven’t considered. The EC team is clearly pushing boundaries, and I’ll definitely be keeping track of the project for inspiration. Who knows - they might come up with solutions to these problems that could inform Hologram’s development as well!
Different architectural choices make sense for different use cases and philosophies, and I think both approaches have value.