5 ms·

Is this production ready? From what I understand, this allows people to arbitrarily decide which portions of their DOM get's run in the client or in the server

Is this production ready? From what I understand, this allows people to arbitrarily decide which portions of their DOM get's run in the client or in the server? Essentially allowing us to make SSR pages with client side code sprinkled in, wherever we want. If so, this seems like a really big deal for Clojure world.

koito17 3y ago
> Is this production ready? It's been worked on for several years AFAICT. It's only very recently that it got a public release, but it was built specifically for use in Hyperfiddle, the company of Dustin Getz (also the same person who developed Electric Clojure). I am not sure what is a good way to determine whether something is production ready, but I know its developers have been dogfooding it for a while now. The only real problem I see is lack of other companies adopting it leading to nobody else wanting to try adopting it. The other big problem is that it's hard selling people Clojure either because it is a niche language or the parentheses scares people away.* * Note I use Clojure in my day job. I do not think either of these two points are a valid excuse to not use Clojure, but they are the most common excuses I see.
- dustingetz 3y ago
  electric has been a team effort, developed primarily by Geoffrey, Peter and especially Leo of https://github.com/leonoel/missionary https://github.com/leonoel/missionary who is the lead developer. the thing predating Electric is in prod at a series B startup, a series A startup is going live with a prod support app in a few weeks, and a seed stage startup is planning a rewrite of a consumer facing productivity tool onto electric after serious evaluation. Plus many serious POCs i’ve seen maybe 2-3 dozen repos this summer. (we only see them when they have a question)
dustingetz 3y ago
not SSR, all rendering is client-side, it’s frontend/backend state sync that Electric solves
- Capricorn2481 3y ago
  Looked into it more. A few questions I have - Is this a lot of bandwidth when done over websockets? I was looking at the starter todo list on your github and everytime I type something a character into the todo list, I have what looks like 3kb of messages in the websocket passed. - Is there anyway to get this working with multiple nodes? It seems like the way to use it is to bind it to a dynamic var that's only available in the library (`hyperfiddle.electric-dom2/node`)
  - dustingetz 3y ago
    you mean like multiple tiers, e/client e/server e/service1 e/service2? sure, we probably get to it next year unless a customer implementation needs it sooner wire protocol is in verbose mode, we have a binary mode as well. it’s also not optimized at all because users already report tangible performance as “incredible” “unbelievable” as compared to the status quo graphql or http RPC or whatever. remember, http transport pays a TCP round trip just to syn/ack the connection before any app payload is sent! Electric wire traffic is also differential, i.e. collections are never sent twice only what changed.
    - Capricorn2481 3y ago
      Thanks for responding. You're operating at a high level and I'm an average coder, but I'm trying to understand It sounds like you're saying Websockets have an advantage as an open connection. It's great that everything is differential, but I'm wondering what exactly is being sent when I type into a `dom/input`? If I write 1000 characters, that's 3mb downloaded. That seems like a lot for typing into an input. What is being diffed here if none of this state is going to anyone but me? I'm sure it's early days in terms of documenting this for the layman, but I hope some day there's a guide that's easy to digest so I know how I could use it myself.
      - dustingetz 3y ago
        the DAG overhead is constant not linear, the overhead is mostly the protocol in verbose mode not binary (the difference is large), and as I said we have done no optimization at all (just naively sync entire DAG replicas on both peers requiring far more traffic than actually required) because tangible performance is excellent so far. 1080p youtube is 1MB/s for comparison and our phones have no problem with that. Framing performance as a compiler optimization problem opens the door to using all of compiler and graph theory to super-optimize this

koito17 3y ago

> Is this production ready? It's been worked on for several years AFAICT. It's only very recently that it got a public release, but it was built specifically for use in Hyperfiddle, the company of Dustin Getz (also the same person who developed Electric Clojure). I am not sure what is a good way to determine whether something is production ready, but I know its developers have been dogfooding it for a while now. The only real problem I see is lack of other companies adopting it leading to nobody else wanting to try adopting it. The other big problem is that it's hard selling people Clojure either because it is a niche language or the parentheses scares people away.* * Note I use Clojure in my day job. I do not think either of these two points are a valid excuse to not use Clojure, but they are the most common excuses I see.

dustingetz 3y ago
electric has been a team effort, developed primarily by Geoffrey, Peter and especially Leo of https://github.com/leonoel/missionary https://github.com/leonoel/missionary who is the lead developer. the thing predating Electric is in prod at a series B startup, a series A startup is going live with a prod support app in a few weeks, and a seed stage startup is planning a rewrite of a consumer facing productivity tool onto electric after serious evaluation. Plus many serious POCs i’ve seen maybe 2-3 dozen repos this summer. (we only see them when they have a question)

dustingetz 3y ago

not SSR, all rendering is client-side, it’s frontend/backend state sync that Electric solves

Capricorn2481 3y ago
Looked into it more. A few questions I have - Is this a lot of bandwidth when done over websockets? I was looking at the starter todo list on your github and everytime I type something a character into the todo list, I have what looks like 3kb of messages in the websocket passed. - Is there anyway to get this working with multiple nodes? It seems like the way to use it is to bind it to a dynamic var that's only available in the library (`hyperfiddle.electric-dom2/node`)
- dustingetz 3y ago
  you mean like multiple tiers, e/client e/server e/service1 e/service2? sure, we probably get to it next year unless a customer implementation needs it sooner wire protocol is in verbose mode, we have a binary mode as well. it’s also not optimized at all because users already report tangible performance as “incredible” “unbelievable” as compared to the status quo graphql or http RPC or whatever. remember, http transport pays a TCP round trip just to syn/ack the connection before any app payload is sent! Electric wire traffic is also differential, i.e. collections are never sent twice only what changed.
  - Capricorn2481 3y ago
    Thanks for responding. You're operating at a high level and I'm an average coder, but I'm trying to understand It sounds like you're saying Websockets have an advantage as an open connection. It's great that everything is differential, but I'm wondering what exactly is being sent when I type into a `dom/input`? If I write 1000 characters, that's 3mb downloaded. That seems like a lot for typing into an input. What is being diffed here if none of this state is going to anyone but me? I'm sure it's early days in terms of documenting this for the layman, but I hope some day there's a guide that's easy to digest so I know how I could use it myself.
    - dustingetz 3y ago
      the DAG overhead is constant not linear, the overhead is mostly the protocol in verbose mode not binary (the difference is large), and as I said we have done no optimization at all (just naively sync entire DAG replicas on both peers requiring far more traffic than actually required) because tangible performance is excellent so far. 1080p youtube is 1MB/s for comparison and our phones have no problem with that. Framing performance as a compiler optimization problem opens the door to using all of compiler and graph theory to super-optimize this