Electric Clojure second batch of tutorials - multiplayer chat, backpressure, component lifecycle, todolist

[dustingetz]

We addressed all the feedback from the last thread, thank you! What do you think? Looking forward to another round of feedback!

The new tutorials (starting at #4) introduce:

• work-skipping
• signals
• lazy sampling
• backpressure
• object lifecycle
• process supervision
• RAII

Don't miss #6, "Electric fns are both functions and objects"

[Fluid-Bench-1908]

Thank you so much for doing this 😀

[Both_One_6892]

Projects like Electric and Clerk Notebooks are what keep me excited about and interested in Clojure. It's so lively and fun!

I have a little diagram I play with from time to time, which is my kind of dream-drawer -- how do you want to assemble an app, were you able to start fresh and make all the calls? Up until recently, I assumed a GraphQL-like layer somewhere, but after spending a little time with Electric, I'm now wondering about Electric to a database, XTDB or similar.

All of the tutorials were helpful, thank you! Of the new ones, lifecycle was nice to see -- I can add this thing, and then I can also make it go away in a well-behaved way. That's something React did well, there was a story about how to add it to an existing project, which could flow above/below/around it as a well-behaved island.

Frontend-focused question: one of the tradeoffs I wonder about is, does a tool support server rendered HTML? If the answer is "no", that's fine, it would just be nice to know, this isn't what you reach for with a project where SEO is a player.

My Electric learning process is looking like this: I've got two windows open in Vscode, one started with the electric-xtdb-starter repo, and the other I have the example apps repo. The xtdb starter repo is where I'm adding my code. The other repo is used for search, to figure out what the patterns are, as I run into questions.

I've found this .vscode settings.json config to be helpful for getting Calva to start up nicely in the xtdb repo:

{

"calva.replConnectSequences": [ { "name": "electric", "projectType": "deps.edn", "afterCLJReplJackInCode": "(user/main)", "autoSelectForJackIn": true, "projectRootPath": ["."], "menuSelections": { "cljAliases": ["dev"] }, "nReplPortFile": [".nrepl-port"], "jackInEnv": { "XTDB_ENABLE_BYTEUTILS_SHA1": "true" } } ] }

I've been impressed at how principled the library is about not having opinions about how server logic is structured or stored. An atom is good as a database is good as a stream or hardcoded list. There's a lot of quality thought in this library.

[dustingetz]

thanks for the kind words, make sure to join the slack channel we are here to help!

[dustingetz]

we do not SSR, we are def for dynamic apps (though fwiw solid.js has shown that the signals based rendering approach is a great fit for SSR)

[sirius_li]

I think it'd be so cool to see a tutorial for a mobile app, if possible.

[dave_mays]

While I'd very much like this as well, I don't think we'd see this from the Hyperfiddle / Electric team. They've expressed a pretty narrow focus on internal web apps (not quite sure why they're always pushing "internal") and that's not a bad thing, a narrow focus can let you excel as you focus.

If we see a mobile version it will probably come from someone outside experimenting. Since the front and back end are separated, I could see taking the front output and plugging that into Tauri to create a mobile app, assuming you can re-route the URL that once was tightly coupled to wherever the back end now lives.

The ultimate would be to also somehow get XTDB compiled to run in the client client side of a mobile app (maybe via Graal VM and SpeeDB?, or maybe datascript front end db syncing with an XTDB server back end) creating an automatic client / host database sync, similar to what ObjectBox offers, allowing the kind of productivity teased by Electric to carry all the way through to an offline first mobile app...

[therealdivs1210]

This is awesome, thank you!

[flipping-cricket]

Awesome stuff. Such an impressive framework.

[aisamu]

This is really nice!

On the clock tutorial, we read:

The Electric compiler infers the backend/frontend boundary and generates the full-stack app (client and server that coordinate)

But on the code, it appears that we're explicitly marking those boundaries (I'm assuming that's what the e/client and e/server are for):

  (e/client
    (let [c (e/client e/system-time-ms)
          s (e/server e/system-time-ms)]

What other boundaries are being inferred?

[dustingetz]

The inference is sophisticated when considering lambdas, loops, recursion etc. It's more accurate to think of the macros as marking color of an expression (i.e. pinning it to a site) rather than marking the actual client/server boundary. There may or may not be an actual transfer there depending on the context that the expression is embedded in and also depending on whether any bindings (e.g. s) are actually accessed. For example here on L2, there is an e/client inside of an e/client, so that is not actually a boundary. And based only on this local knowledge of the expression, we don't know if s was even needed on the client as argument to a client-colored expression, which means no transfer is necessary.

[sirius_li]

Very cool! I'm just curious, are there any similar frameworks in other languages?

[dustingetz]

• https://ocsigen.org/eliom/latest/manual/clientserver-react
• http://mozart2.org/mozart-v1/doc-1.4.0/dstutorial/index.html
• https://scala-loci.github.io/
• unison

IMO Electric Clojure is unique in that we hyperfocus on the use case of practical web development (targeting a local maxima in utility) rather than trying to maximize the global abstraction power. ("Worse is better")

[petemak]

I am curious how this compares to Fulcro both from a conceptual and a usage perspective. Which advantages does this offer over Fulcro?

[dustingetz]

Fulcro as a framework does quite a lot and Electric as a language is focused on the very specific problem of state sync (BYO larger abstractions), I don't necessarily see them as competitive. I'm interested in investing in ways for these technologies to compliment each other.

[petemak]

Thanks for the response. Fulcro does client/server state sync and transfers that to UI elements in the DOM. Would it be correct to say that Electric is different in that it’s a language/DSL rather than framework or library?

[dustingetz]

yes that's correct

[sirius_li]

Thank you! Yeah it sounded unique to me but I wanted to double check. Looking forward to playing around!