Clojurians Log v2
hyperfiddle
are there examples of optimistic update for v3? i am building a canvas with node drag, and upon node drag, it sends the new pos to server but server sends old pos such that there is momentary jerk back to original position. then it syncs up with the new position.
yeah you need to make sure the client is the source of truth and that the rendering loop never leaves the client. Presumably you're streaming drag coordinates through the server for multiplayer, you need to take clear to construct a topology where the server paths and client paths are distinct, and if conflicts are possible in a multiplayer situation (two sources of truth for one object) you'll need to deal with that and merge the local and remote signals into a coherent view
I don't think we have any good examples of multiplayer drag drop (we certainly haven't built the CRDT mechanism to resolve conflicts)
thanks yeah this is quite complex but necessary for snappiness
got it working via e/Token on server data, neat.
Next week at The London Clojurians: *Link into your REPL with http://clojure.net, from Hyperfiddle (by Dustin Getz)* https://www.meetup.com/london-clojurians/events/313632474/
meetup today, this afternoon/evening
Is there an online meeting link for later? RSVP'd on Meetup, but can't find a link to join.
Connection details will be shared 1h before the start time
there is a sense in which claude enjoys working on electric, which ime improves its mood and performance. it makes sense since claude has always been the most aesthetic model. codex on the other hand doesn’t get it. codex has historically been very bad with complexity (yesterday it created a ten-argument e/defn). most of its valuation is utility-based, which is less sophisticated than aesthetics-based valuation. i haven’t tried electric with any other models, i’d be curious as to how kimi fares (kimi’s also aesthetically rich) one gripe with claude is its difficulty with parentheses… honestly 30% of dev time goes to agents trying to match parens. forces factorization but still annoying
my biggest gripe with LLMs is this: humans have a limited working memory. We need to decompose problems and have a clean way to compose them back. Our limits enforce constraints on what we can achieve, but also on the complexity we create. LLMs can bypass this. They can read and write much more complex code than us humans. This raises what they can achieve, but also the complexity they create. Electric simplifies UI code by an order of magnitude. Both humans and LLMs should appreciate this. More importantly it should improve the LLM's efficiency - a cleaner model/programming language is simpler to read and write
beautifully put. simplicity is not valuable to a divine being, since he could just spend infinite compute/time on anything. simplicity arises due to limitations and elegance follows. an amusing outcome might be that complexity in codebases becomes even more important because it’ll reverberate via ai mimicry
ai researchers tend to resist anthropomorphization of llms but they’re our statistical shadow. they should be able to appreciate simplicity just the same. if we train them on better data over time (and intelligence improves), their appreciation of simplicity should increase
More importantly it should improve the LLM's efficiencytoday's AIs form a great accidental-complexity test: for a problem with a known solution, if the AI does it an order of magnitude faster than you - congratulations, there's so much accidental complexity you're losing it. Electric is a good example of this - data binding, HTTP APIs with routes, headers, query parameters etc etc, all gone. Building a screen is considerably simpler
@hendrik.levering sounds like a tooling issue. I.e. given a good skill/mcp/... I don't see why the LLM would see an increase in the feedback loop. The exceptions are in stderr/js-console, the UI is in the browser; building a UI with any other technology has the same outputs.
UI code is historically challenging to test, the new Nolen architecture is request/response simple function composition and therefore more unit testing friendly (in theory, though idk in practice, i am skeptical that asserting the HTML matches the declaration you wrote is a useful test). Electric brings UI closer to pure functional but it is reactive functions with a time dimension, we haven't yet figured out how to test Electric UIs
maybe. However there is one advantage to the datastar approach. They had one post endpoint taking an action id. for a session view they stored all possible actions on the server, so most of the time you could basically stay in the repl and just invoke a function returning the hiccup and (with a little enhancement) the list of all next actions in that view. which gives the agent great feedback as long as you do not have to check for visuals.
We do use async RCF tests internally which works pretty well but applying this framework to like, a select option widget, or our virtual scroll datagrid — things entangled with an effectful DOM—is not obvious
sth i did not expect is how automated backend is becoming while frontend retains a human moat. anything visual (or interactive/realtime like games) agents are quite bad at
I agree testing UIs is still hard, electric doesn't help here. What I don't see is how it'd impede validation feedback compared to the status quo. If you see gains here with datastar, great.
Electric does not impede validation feedback compared to status quo. There are just new interesting approaches (like the one I mentioned), that give better LLM feedback than the status quo.
@joshchonpc all of my paren issues went away after installing clj-paren-repair-claude-hook, which has zero impact on token usage:
https://github.com/bhauman/clojure-mcp-light
What LLM agent setup/hooks would you recommend for Electric? I'm currently trying to figure out how to use https://github.com/licht1stein/brepl/ to evaluate CLJS code on the same nREPL server.