Clojurians Log v2

correct

you want https://gitlab.com/hyperfiddle/electric3-starter-app

i will archive that superseded v2 repo now

Worked beautifully. Might want to add a note about it no longer working, point to the gitlab repo, etc.

sorry about that, we are still artifically suppressing adoption of electric v3 - maniacs only 🙂 I will try to improve docs and add more notes

(hence not wanting yet to publish the url to github)

LOL. Understand.

For the record, what I'm trying to do is; replace a low-code app written in AppSheets with an Electric app that can be deployed from a static site. Exploring how a one-man consultancy can move small clients from to the next step beyond spreadsheets. And learning how to use AI to help with that using Windsurf. 😀

can you share screenshots of the app you're looking to replace?

deployed from a static sitedoes this mean no server? i don't understand

Can't really post screen shots. Proprietary data and all that. Yeah, no backend server. No idea if that's even possible. Like I said, exploring. And mostly want to learn Electric since I've been watching you develop it for so long. As a one-man shop, I need a path to move my clients easily beyond AppSheets and the like. A simple that runs entirely in the browser seems like the next smallest step, if it's possible. Might not be.

browser only is possible, in v3 it works in principle and we even want it to be a supported configuration, but we are not formally testing yet in that configuration right now nor do we have any customer projects doing it

i think the feature may be disabled right now due to a separate bug (related to "seamless reconnect after server disconnect" - which is also currently disabled, because it's buggy)

Cool. I'll let you know when I get that far.

Victory is near

ha ha we have several war stories, the team is welcome to share if they want

here's a copy/paste of something from our issue tracker: > Before we added HTTPKit support the server sent PING frames to the client. The client responded with a PONG. If the connection was idle the server closed it. > HTTPKit doesn't have websocket PING support [1]. To support and unify with Jetty we changed heartbeats - now the client sent a special HEARTBEAT message to the server periodically [2]. > This resulted in a regression. Chrome throttles a hidden tab's timers after 5 minutes [3]. They tick in a batch once a minute. We set the max allowed idle time for a connection to 59 seconds since we deploy to http://fly.io which kills every TCP connection idle for over 1 minute [4]. The result - in Chrome the connection dies and reconnects in a loop. > This commit overcomes all of the above limitations. The server takes back the initiative and sends a HEARTBEAT message to every client. The client sends a HEARTBEAT message back to the server. This way > • we don't rely on websocket PINGs (since HTTPKit doesn't have them) > • we don't get throttled in Chrome (since we now rely on server timers) > • we fit into Fly's 1 minute limit > > [1] http-kit/http-kit#350 > [2] 6008d18 > [3] https://developer.chrome.com/blog/timer-throttling-in-chrome-88/ > [4] https://community.fly.io/t/app-connection-timeout/5369

so basically, every layer of the stack can fuck you - chrome/firefox, webkit/jetty, http://fly.io

another good one was - our two-clocks demo, the hello world first page that everyone visits, streams a clock from the server at 100hz or something, and back in the day, if you went there on mobile, but then like got bored and went somewhere else but left the tab open, your phone—random people's phones—would get hot in your pocket and your battery would die, because, the websocket standard still does not have backpressure (!!!!) which means if the server sends network messages, the browser can't just drop them, it has to consume them, and the browser has no way to backpressure that, which means the app has to keep running, which means your radio has to stay on to receive a stream of nil nil nil ticking at 100hz which is like 10kb/s or something outrageously high after overhead. And when your smartphone's radio is stuck on for 4 hours, plus something like 50% CPU that whole time to deserialize and process 100 server events per second which is writing to the DOM at the browser animation rate, your phone will become hot to the touch in your pocket from sustaining high CPU for four hours until the battery dies. Luckily I spent like 5 days just looking at our website nonstop on my phone to make sure it was up, so pretty quickly connected my too-hot-to-touch-phone-with-dead-battery to electric and we got it fixed before anyone really started complaining iirc.

We fixed that one in userland, with this extremely beautiful Electric one-liner where we subscribe to the DOM visibility state change event on the server so that the server can know to stop ticking the clock when the client tab isn't in the foreground

https://github.com/hyperfiddle/electric/blob/2795996813f2d92e4be0274e173e8b50e95acc73/src/hyperfiddle/electric3.cljc#L460-L462

> so basically, every layer of the stack can fuck you - chrome/firefox, webkit/jetty, http://fly.io (edited) WebSockets is the Australia of web tech 🤣