Lisp/smalltalk programmers have been going on about this tradeoff for a long time. It mattered before LLMs too. Lisp/Clojure repl allowing you to compile tiny parts of your program inside your running program is incredible for your feedback/iteration loop.
Ironically, this is also what makes them shine with LLMs, the LLM has access to the running program and can modify it while it's running to get feedback instantly.
Complex type systems are cool. But, they are not free. I say this as someone who's first programming language was Haskell.
Yeah, it's an intellectually intoxicating idea but incredibly hard to get right.
For me the problem is that in practice it only fits really well with quite a specific subset of problems, but we desperately want it to be a general solution that can apply to all the things (or at least it's often marketed that way).
> Generalization breaks down for offline-capable applications. Offline writes require conflict resolution, create authorization edge cases, and demand coordinated schema management across server and client replicas.
> ...These constraints are structural; engineering effort cannot remove them...
> The trade-off analysis shows that three sync engine vendors converged independently on this conclusion from different starting positions.
This is the big irony. That the vendors all converged on the fact that sync engines only really "work" when you remove the offline part. But, at that point they are a complicated/over engineered cache or worse introducing hard distributed computer science problems unnecessarily.
I feel like independent thought will decrease considerably with LLMs. I wonder if they will effectively become oracles in the sense that the average output of an LLM will be what most companies do therefore you can predict what most companies will do.
Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip.
User permission can often be very dynamic. Sync engines (local first ones even more so) give them access to a much larger set if that data in a client side database.
This also makes them much more vulnerable to a data leak/breach if their device gets compromised or stolen as the data is all on their device.
The client having access to only what it needs in terms of data and making that as ephemeral as possible is a big part of defence in depth.
You don't even need your backend that close if your server is fast enough. Streaming HTML immediate mode is pretty good. See this demo (server is in Germany and runs on a potato uses no optimistic updates, eveb scroll round trips) [1]
Honestly client side animations go a long way to masking latency too.
Sync engines are fast to a point but if you start working with large enough datasets and/or care about security you ultimately end up with something closer to streaming immediate mode HTML. Of course that means sacrificing local first.
Although not as prominent as insert SELECT and UPDATE both benefit from page cache locality, assuming rows that are stored near each other are often selected/updated together.
An insignificant amount for the comparison (why I didn't mention it), it's a fast implementation and the JVM C2 JIT has kicked in by the time the first batch has completed.