Clojurians Log v2

I hear a bit of a change of direction, that Electric is now designed for dedicated always online apps. For contrast here is a statement that comes from the original V.3 Two Clocks demo: FAQ: Can you use Electric from ClojureScript only without a server and websocket (e.g. as a React.js replacement)? Yes, as of v3 this is officially supported! I'm just wondering how, if at all, this statement is going to survive into the new documentation.

https://docs.google.com/document/d/1frkb5URGFZUdWyCDl9moGFcPcLuDtW-M-HnCJOHkuDA/edit?tab=t.0#heading=h.pfju9xanf2lp

a part of our test suite runs in a single peer (no server) setup. But we don't have a good reason to provide official guidance. I.e. we can direct you how to set it up but won't promise stability

I assume it is the fault of the websocket connection, but when I walk away from from our router while using an Electric app on my mobile phone, at some point the screen goes blank. I would hope that with no server interaction being done (the app has its own atom) the app would just keep going. It needs to read from the server on startup and saving is being done in a connection-fault-tolerant way. I'm sure I could write it as 'client-only' as far as Electric is concerned, and perhaps I could use your reference 'test suite guidance' for that. But there's a wider concern as well. There has been talk about long-polling as a fallback. Was this so that in general no Electric programs ever get blank screens?

this is a known bug, it's on our todo list. Long-polling was not about blank screen, that's just a bug. Long-polling would be an option to use instead of a websocket, in environments where websockets are not an option. Just like webtransport might become a viable alternative to websockets, once safari decides to support it

Okay thanks. Glad to know that the blank screen problem is a bug. That in the future my app will keep working with terrible connections, as we have where I live!

1. electric is indeed designed for always online apps, if you're using electric entirely without a server, you're missing the entire value prop of electric 2. intermittent connections is a fact of life (in SE Asia and also everywhere else), we do see a need for Electric to not teardown the app/page when connection is lost (instead keeping the client running until the server comes back and gracefully reconnecting). We built the feature, but the feature is buggy, so we turned it off until we have time to work on it, and nobody is paying us for this yet soooo ... 3. thank you for pointing out the broken promise, I think what we learned is that Electric makes many tradeoffs and I doubt the tradeoffs are worth it if you don't have a server. Example: Electric has poor performance when rendering collections size 100-500, and we don't care, because we virtualize all our collections to support sizes up to 50,000, and sub-500 is an edge case of that. You can of course also virtualize your collections in a frontend-only app (maybe you should) but I doubt you will be happy about it, given that React can do 50-500 records just fine. Note that when feature #2 is turned back on, client-only apps is just a limiting edge case where the server is always missing, so the feature comes for free

i will add this to the FAQ

> electric is indeed designed for always online apps, if you’re using electric entirely without a server, you’re missing the entire value prop of electric Is there not value in a language that’s reactive at the expression level, and that makes the initial transfer of data from server to client extremely easy, and in dev easily changing what initial processing is done on the client and what on the server? That’s mostly how I’ve been using Electric, and it makes me happy. 🙂

FWIW this particular little app is for say at a restaurant/shop. The menu needs to be loaded at startup but you don't want to stop taking an order from a customer just because the internet goes down for a bit - so it is a client-biased app for that reason. Orders will have to be saved to the server, but eventually (when the connection is good again) is good enough for that. This was one of my learning apps and may never be deployed - but I'll no doubt get excited about it again when Electric can handle intermittent connections.

@nomiskatz yes there is value in that and yet if you look closely at the primitives/idioms Electric provides, such as for differential dataflow, virtual scroll, and transaction management (token), they are all about distribution and latency management. As Electric matures there is a risk that the primitives and idioms diverge more and more from a client-centric use case. What we optimize, what we don't optimize, all of our investments are rooted in this fundamental assumption of a server

BUT if it works for you, we are happy to see it

Hot code reload doesn't auto reload clj files (https://clojurians.slack.com/archives/C7Q9GSHFV/p1748951615784259?thread_ts=1748884219.773189&cid=C7Q9GSHFV)

Love the front matter, it's very clear and satisfies the curiosity I've had about the project's context and goals.

• Loved the honesty - Electric is about money, and learning curve is steep • Also like the hate for VC-funded slop. Would think twice about giving such Russian feedback to investors though. • I would definitely add right at the start: a one-liner slogan, and TLDR (elevator pitch) version, which a non-specialist can understand. ◦ I've programmed for 9 years, little of it web, and I struggle to grasp the value proposition from reading terms like 'backpressure', 'UI as a concurrency problem', 'differential dataflow with signals', etc. ◦ What makes me understand Electric's benefit is the following. Electric vanquishes the need for a ton of work (network plumbing), by seamlessly interweaving full-fledged web/server Clojure/Script, similar to how Clojure saves programmer time with homoiconicity (code/data dichotomy), REPL (development/runtime dichotomy)

The preamble before the tutorial is very well written! I can tell a lot of thought when into phrasing around expectations regarding paid vs non-paid users. Nicely done Hoping things work out for you and your team sooner rather than later. 🚀 And hoping I can sell it at my current company soon. 🤞

The comment about being able to rewrite in TS was interesting. Have been toying with a similar idea for a while. (Compile time coreographic programming a la React server components but real-time. Possibly as a Vite plugin) Ironically a different Electric (local first DB sync thing) recently released a DD implementation for TS: https://github.com/electric-sql/d2ts. I agree with your sentiment that it’d have much wider appeal to begin with but ultimately would be more limited.

All makes sense to me, reads well, clear. Most interesting for me was that you struck out “enterprise apps and internal tools”, which I thought was still a target. However, seems to be true in our case that managers / heads are not keen on the clojure / backend team building internal tools using electric. I’d be interested to find out what they’d think about buying licenses for low-code tools, like a re-tool that actually handles the hard bits, and how you imagine that being priced. I love the thought of electric enabling next-gen apps that weren’t possible before. I wonder what those will be. I’m personally looking forward to discovering what the next game-changing abstract interface will look like - in the way that the spreadsheet, the kanban board, and then the collaborative spreadsheet, the infinite canvas have all been incredibly pervasive models that were enabled by technology changes. What will electric enable, that we haven’t yet seen in the world? Going to be honest - I’m unlikely to be someone that develops that unicorn next gen app - however I do hope to contribute some fun collaborative music-related apps that would either be impossible or just unpleasant to write in any other way, and to present a conference talk out of it… tl; dr docco looks good, grateful for knowing about the project and having access to the electric starter kit, looking forward to building my electric skills and making some things.

We're quite happy for you to develop your music apps with Electric! I hope that is clear

Yes definitely! The "hope" was more about my side ha a hope that I will develop the skills needed :)

re enterprise internal apps, electric is a good fit, several companies are extremely happy with electric v2 for internal apps such as that one 3E project iirc. But the problem is that we've lost a few deals to HTMX because Clojure devs are basically sick and tired of heavy overengineered ClojureScript frameworks which have totally failed to deliver any alpha at all relative to the TypeScript/React baseline, it's a legacy debugging nightmare, and they are now responding by rotating hard in the other direction for the promise of simplicity. Also, businesses generally value dev productivity a lot more than quality for their internal tools - a scrappy, even crappy result is often adequate as long as it's done without fuss, who cares if the UX is terrible. So Electric's learning curve is hard to justify. We've had IC level devs kill an Electric effort outright because they're scared of it, they have to learn a new thing and what if they can't keep up? What if they get laid off? Companies after the Covid boom are filled with imposter devs, juniors with senior title using chatgpt to survive. With HTMX, anybody can learn it (and if the result in six months sucks there will be no consequences). The teams who love Electric the most are always those doing next gen stuff that couldn't otherwise exist.

"Talent hits a target no one else can hit; Genius hits a target no one else can see." ;)

Also "crud apps" have many different levels of sophistication, Airtable is technically CRUD, all the way up to, idk, Jira. All under the umbrella "CRUD", which word was stolen by the airtable/lowcode market. There's no good litmus test to objectively establish where any given enterprise app is on that spectrum, at what metrics HTMX falls over and you need something more powerful, etc. All reasons for us to just avoid the category in our marketing materials. I'm sure we will continue to see many people use Electric for enterprise stuff especially as the higher Hyperfiddle components start to come online. Our marketing message will be: use electric for all this super advanced stuff (and btw if your requirements are not advanced, clearly we can handle it while also giving you a path to future advanced stuff)