Hacker News Reader

Comment by teoingdri | Hacker News Reader

Love Clojure, but am repulsed by the idea of a “responsive DOM network stream”.

This feels over engineered to me. The classic cool factor influencing the “if we could vs if we should”, bolstered by developing it as a software engineer on a performant dev box with impeccable internet connection; hell, maybe even a local dev db clone.

I suppose you could argue server side caching would alleviate some of the pains of a design like this, but you’re still performing redundant server round trips for the stream when a piece of data goes in and out of view.

Does the tech have any local caching options to make this a little more sane for a worst case an end user?

View on HN

> you’re still performing redundant server round trips for the stream when a piece of data goes in and out of view

This is not the way how Electric apps work, this was just a demonstration of how easily you can orchestrate complex network-transparent client-server interactions _when_ you need them.

Have you tried it? I was skeptical too until I built a few apps with it. The learning curve is easier than it seems (I started by modifying the examples) and it really does cut down on development time - turns out much of modern web programming revolves around network management and its associated complexities.

> Does the tech have any local caching options to make this a little more sane for a worst case an end user?

This is trivially solved in Electric- as long as you hold onto a client-side handle of the data, it won't be unmounted.

Re. performance - Electric v2 is already faster than alternatives for many kinds of apps (not all). We expect v3 to be so fast that it can express apps that are outright impossible with alternatives. The robotics observability IDE in the talk, for example, as well as Hyperfiddle itself.

Re. server caching – Electric (being reactive) auto memoizes all scopes, even on the server. (The essence of reactive programming is a time/space tradeoff - cache more things to minimize recomputation later.) For example, in the virtual scroll demo from the talk, the database query runs once and is retained in memory, so that scrolling simply indexes over the memoized collection:

    (defn window [xs offset limit]
      (subvec (vec xs) ; fast cast
        (Math/max offset 0)
        (Math/min (+ offset limit) (count xs))))

    (e/defn Window [query! offset limit]
      (e/server
        (let [xs ($ e/Offload #(query!))] ; retain and reuse xs as offset changes
          [(count xs) (e/diff-by identity (window xs offset limit))])))

Regarding client caching - it's basically the same. Hoist the value you want to save to be above the conditional that is disposing it. If that doesn't work, use an atom.

Reply on news.ycombinator.com