Comment by jitl | Hacker News Reader

Comment by jitl | Hacker News Reader

Parent Full thread

But, does Replicache work for your native targets? Or you are okay with a different data layer for native (sqlite) vs web (boutique data model on top of IndexedDB). At the start of the article it sounds like the goal is to use the same abstraction across web and mobile native and solutions that bifurcate implementation are unacceptable, but then we end up preferring a solution that's different between web target and native targets.

Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed; like SQLite-over-IndexedDB, I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records. The big difference between SQLite-over-IndexedDB and Zero-over-IndexedDB is that Zero is written with sympathy to IndexedDB's performance characteristics, whereas SQLite is written with sympathy to conventional filesystem performance.

On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong.

Hi replicache/zero guy here

> Zero (and I believe Replicache as well) layer their own SQL-like semantics on top of an arbitrary KV store, much like the layering of SQLite-over-IndexedDB discussed

Replicache exposes only a kv interface. Zero does expose a SQL-like interface.

> I believe they are storing binary byte pages in the underlying KV store and each page contains data for one-or-more Replicache/Zero records.

The pages are JSON values not binary encoded, but that's an impl detail. At a big picture, you're right that both Replicache and Zero aggregate many values into pages that are stored in IDB (or SQLite in React Native).

> On the subject of "keep whole thing in memory", this is what Zero does for its instant performance, and why they suggest limiting your working set / data desired at app boot to ~40MB, although I can't find a reference for this. Zero is smart though and will pick the 40MB for you though. Hopefully Zero folks come by and corrects me if I'm wrong.

Replicache and Zero are a bit different here. Replicache keeps only up to 64MB in memory. It uses an LRU cache to manage this. The rest is paged in and out of IDB.

This ended up being a really big perf cliff because bigger applications would thrash against this limit.

In Zero, we just keep the entire client datastore in memory. Basically we use IDB/SQLite as a backup/restore target. We don't page in and out of it.

This might sound worse, but the difference is Zero's query-driven sync. Queries automatically fallback to the server and sync. So the whole model is different. You don't sync everything, you just sync what you need. From some upcoming docs:

https://i.imgur.com/y91qFrx.png

Notion screenshot ;)

Big fan!

I really like Zero’s approach: it feels very much like Triplit, including many of its features like query-based smart caching. However, what holds me back from using it is that, unlike Triplit, Zero currently lacks support for offline modifications, which must be a major obstacle for a truly local‑first library.

Zero isn't trying to be 'truly local-first'.

We're leveraging sync to make high-quality online software. We may come back to offline in the future, but it's not the priority today.

You can read more about our approach to offline here:

https://zero.rocicorp.dev/docs/offline

strange then that is always mentioned as one of the most prominent local-first engines.

The terminology in this area is still in flux, but for past year or so I've been trying to draw a distinction:

https://i.imgur.com/B5iOd9y.png

https://x.com/search?q=aboodman%20local-first%20zero&src=typ...

Yes, Replicache works beautifully on our mobile/native targets.

The constructor allows you to pass in any arbitrary KVStore provider, and we happen to use op-sqlite as its performance is exceptional.

There is no "different data layer" per se, just a different storage mechanism.

Replicache also holds a mem cache that is limited to ~50MB if I recall. Our use case is extremely data-heavy, so we might end up never migrating to Zero – who knows.

Perhaps I misunderstood your question, let me know if I can clarify further.

Ah, I understood "native application in some targets" to mean you're writing application code in languages other than JavaScript/TypeScript; not that sometimes you're React Native and sometimes you're Web/DOM but you're always TypeScript.

Notion always* has a webview component, even in native apps, but we also have a substantial amount of "true native" Swift/Kotlin. We can't use Replicache/Zero today because our native code and our webview share the SQLite database and both need to be able to read and write the data there; if we use Replicache that would make our persisted data opaque bytes to Swift/Kotlin.

*There's many screens of the Android/iOS app that are entirely native but the editor will probably remain a webview for a while yet.

Yeah that makes sense for your use case. We're RN for web, mobile, and desktop, so it works smoothly for us.

Reply on news.ycombinator.com