1. Paraphrasing Dustin; there’s a reason why we have garbage collection, reference counting, Rust’s borrow checker etc., and it’s because manual memory management is unnecessary not to mention hazardous for the vast majority of projects. Unless you’re working on the Mars Rover, you should probably stick to GC. The same applies to network comms management: it’s error prone, hard to reason about, and full of pitfalls once you get beyond even simple load/message passing scenarios. Leave it to the compiler. It’s not efficient to have a human figure out timing and ordering of networking once it gets even slightly complex. 2. I don’t have a good answer for this one. As with 1, part of the value prop of Electric is that the network boundary becomes fairly transparent, and easy to move around. Server and client logic becomes colocated. There’s of course nothing stopping you from designating parts of the app as “frontend” vs “backend”—that’s a design question, not something imposed on you by the Electric, as it is with most other frameworks. 3. We’re using it in production. 4. With REST the server is “over there”, with Electric it’s “over here”. I’ll give you an example: I refactored our authentication logic recently. The flow looks roughly like this: 1.0 From the client, get the current URL and query parameters, send them to the server. 2.0. On the server, parse the query parameters, and get authentication code if it exists 2.1 If the code exists in query params, call an API to exchange for a JWT. 2.2 If the code doesn’t exist; on the client, mount a hidden iframe and perform a silent authentication and get the code, if possible. Send to the server to exchange for a JWT. 2.3 If the server has no JWT at this point, the client redirects to the login page and perform a non-silent login. Go to 1. 3.0 On the server, use the JWT to get user info, pass them to the client. At the same time, the client, scrubs the URL of any codes. There’s a little bit of back and forth going on here, but enough that the benefits of Electric were obvious when I wrote it. If I also had to splice in network coordination in this, which amounts to building a state machine that spans client and server, it would have been much more work than it ended up being. Add in the UI and cosmetic layer; showing the right buttons, error messages, spinners etc. at the right time, and it would have been a fair sized task, but it wasn’t.

With all that said, there’s a fair amount unlearn when you start using Electric as well. For me it came fairly naturally, but that’s not necessarily true in all cases.

One possible FE/BE split - the BE team works on the business logic (no electric) and the FE team calls the BE logic where necessary

I'd add to @U06B8J0AJ response for no 2 that the separation in bigger companies of FE/BE was necessary as that was the only way to do it. Maybe now, you can divide again the project by features/scopes and have teams develop with electric the entire feature not just the FE or the BE of it.

I am rewriting the same project, now with electric and the amount of code I don't need to write again is staggering. Before I was using re-posh, reagent, datascript and on the server datomic ions. A lot of the code was handling FE/BE communication, it is completely gone. And now I am tranfering less data and only when needed (e/for-by magic )

Thank you guys, your responses really give me context.

Special thanks to @U06B8J0AJ for such a detailed writeup 👍