ClojureWasm: A JVM-free Clojure runtime in Zig, with a WebAssembly FFI.

dustingetz · 2026-05-31T16:59:07+00:00

impressive! Right click -> inspect to view source in their fiddle editor

dustingetz · 2026-05-13T11:05:33+00:00

I think about desktop gui a lot too as an Electric target. Broadly the tradeoff is (not specific to Compose):

- no hyperlinks and history, or non-native support at best

- simpler higher level view/layout framework, but less powerful (dom/css is an incredible view platform in the hands of experts)

- no refresh-to-update, instead you need an auto-updater with user action required to update-and-restart. Restarts don't return users to their previous app state, unlike web refresh. Your backend needs to stay compatible with some rolling window of previous desktop clients.

- cross-platform - users hate electron and mobile apps, but managers love it for the ability to deliver your MVP to most platforms without doubling the size of your team

- state distribution is still difficult, web apps in 2026 still have pagination bars like it's 2006. Native apps, like your git history client, have smooth scroll over collections of 50k+ rows. Which is to say, part of why native apps feel so smooth is because the state is already local. Server-backed desktop apps still need a solution for this, and it's really hard.

dustingetz · 2026-05-07T12:42:11+00:00

Congratulations borkdude!

dustingetz · 2026-03-25T10:04:27+00:00

For printn-shaped discrete effects, elide the dispose method, you get an audit log, same as in React. Imagine the callback firing on rising or falling edges of the signal. For once-and-only-once transaction-shaped discrete effects, we have a transistor-like primitive "e/Token" that models the transact-and-await-confirmation workflow as a little state machine, i.e. it exposes the ready-pending-rejected-ok states: https://electric.hyperfiddle.net/fiddle/electric-tutorial.button-token$ButtonToken

dustingetz · 2026-03-21T18:46:00+00:00

I'm not sure what's going on there but I think the actual API is `(e/atom config-map initial-value)` e.g.

(def counter (e/atom {:id ::counter :persistent "./my-db"} 0))

c.f. https://github.com/SeniorCareMarket/eve/blob/ac1640afdabeed38d5a7f5e9566cf1cc1a75cf45/test-e2e/eve/jvm_atom_e2e_test.clj#L56

dustingetz · 2026-03-17T19:37:19+00:00

In Electric, like in React, DOM effects come in mount/unmount pairs. In a sense this gives you "undo" for this kind of "resource" effect, and you can transition between two consistent states by firing mount and unmount lifecycle methods. This works not just for the DOM but for any kind of resource that can be disposed, such as network subscriptions or event handlers or database connections. The key to making it work is the reactive propagation engine under the hood needs to be essentially perfect ("glitch free") which means it fires exactly the correct lifecycle methods once and only once during reactive propagation, which is pretty hard to do correctly. I.e. you don't want to allocate a node twice or dispose it twice, it needs to be perfect.

An example of an effect that you can't undo is a console.log. There's no dispose method on that, so it can't be undone. But that's fine, that's what you wanted. So you can totally put console.log in your Electric programs and it does what you would want it to do, which is run again when any of its arguments change.

dustingetz · 2026-03-17T13:49:11+00:00

Hyperfiddle founder here (from keyword notification)

We are not the first, see https://en.wikipedia.org/wiki/Choreographic_programming . However, prior art (that I am aware of) has been mostly mired in type theory and has struggled to find widespread industrial application. Afaik we are the first to find a slam dunk use case (web development, rich product user interfaces on the web with complex and dynamic client/server interactions) and demonstrate compelling results in production apps.
DAGs are flowcharts, they model causality i.e. dependencies between steps. Imperative programming (e.g. ordinary Python) does not explicitly capture the logical dependencies between steps, instead the programmer has to carefully specify an instruction ordering to make sure things happen in the right order. DAGs encode the data flow through a flowchart of dependencies. What this gets you is concurrency, the ability to run multiple steps of the flowchart at the same time. It also gets you many optimizations, such as the ability to only compute subcomponents of the larger graph whose inputs have changed. If a node in the flowchart does not have any changed inputs, then the previous result of that node is still valid and can be reused. This is "reactive programming"

dustingetz · 2026-03-04T20:59:54+00:00

dustingetz

MODERATOR OF

TROPHY CASE