2024 July 31 by Dustin Getz - https://twitter.com/dustingetz

Electric is a new way to build rich web products with Clojure that simply have too much interactivity, realtime streaming, and too rich network connections to be able to write all the frontend/backend network plumbing by hand. If this is your first time seeing Electric, the tutorial is a good place to start.

Much has changed since our last progress update. Early adopters have been running Electric v2 in production since last summer, to build sophisticated interactive web products such as a Notion-inspired marketing tool, a visual studio IDE for industrial robotics, database apps and of course AI-native product experiments.

And with their support last year we worked out the kinks: we have stable hot code reloading, fast incremental builds, faster sync performance than React-based dataloader frameworks, and dealt with the dreaded “Too Much Recursion” error when your Electric program got too large. (Did you know Chrome’s JS parser crashes on javascript programs with 250 levels of closure nesting?)

Electric v2 upgrades since launch:

• Clojure/Script compatibility is more or less finished
  • Electric functions support apply, varargs, multiple arity, recursion
  • clojure/script interop is finished, platform reader conditionals now behave as you’d expect them to do (paving the path for code linter compatibility)
  • core.match and core.logging support
  • Clojure 1.12 support
• stability and DX
  • stable hot code reloading
  • async stack traces (they interleave client and server frames into a unified traceback)
  • dealt with websocket disconnects when Chrome throttles timers, causing heartbeat misses
  • fixed “Too Much Recursion issue” - js compilation output exceeded hardcoded closure nesting limits in browsers
  • starter app improvements
• ops improvements
  • batteries included build and deployment templates
  • streamlined deployment, auto-wire client/server build hash check
  • HTTPKit support added
  • upgrade to Ring 1.11 (websocket release) for simpler middleware - see changelog
• electric-dom2
  • improved dom event handling strategies that are concurrency- and latency-aware
• libraries
  • hyperfiddle.history prototype (see Electric Fiddle repo)
  • fulcro integration example
  • XTDB example
  • Auth0/Electric integration
  • Biff/Electric integration
  • Rama/Electric integration

Electric v3 is coming!

With Electric v2, we demonstrated that we weren’t crazy, this thing is commercially viable in real apps. But it also had growing pains. v2’s electric lambdas in particular had a couple annoying rules that had to be learned, which has historically been a big sticking point for many people.

Electric v3 is a rewrite of the network runtime, which removes technical debt and tightens down the language’s semantics in order to fix and resolve all of our biggest issues preventing Electric from delivering a bulletproof experience that scales to the most aggressive, high performance user experiences.

Electric v3 quick preview of major changes:

(We’ll be sharing much more detail about this in coming weeks!)

• Intuitive transfer semantics!
  • fixed language semantics issues causing values to transfer over network in unintuitive or arbitrary ways, in particular fixing all issues with Electric lambdas that were causing userland programs to need too many macros
  • electric lexical/dynamic scope is now unified, no more duplicated bindings (i.e. existing on both client and server separately)
  • dynamic siting - a tweak of client/server site resolution rules to allow writing site-agnostic code