> Why would jurors be harder to buy than career politicians?

Because the juries are selected from random pools.

Are you truly sincere in your question regarding the ability to buy off career politicians vs random peers?

Are you aware of jury tampering laws?

> The other obvious problem is jury selection. You can basically choose the outcome by selecting the "right" jury.

I was unaware you are so passionate about reforming the current jury system.

What groups are you currently working with to improve the existing system?

I can agree there are flaws in the current system but rather than throwing my hands up in defeat I think such problems can be addressed.

How would you better address the issue from the linked article?

> 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.