But that is a kind of silly way to compare. Broccoli isn't very filling _and_ it doesn't have very much protein in it. That doesn't change the fact that it lack protein.
The question is if I'm preparing a meal that I want to be filling, healthy, and energizing, how should I do it. Broccoli isn't a good answer to the protein part of that question.
I live in Hawaii where the Toyota Tacoma is basically the state mascot. I owned almost exclusively sedans before I moved here. A friend from the bay area moved here several years ago and argued he wouldn't need a pickup, but ended up getting a Rivian within a year or so.
The pickup is more practical than a van here because you end up hauling a lot of dirty/sandy/wet stuff. Yes, you could put this in your van, but hooray now you have sand and water in your van that you need to clean out (and you do need to because the heat will turn it into mildew immediately if you don't). The bed of the truck is outside. It dries out on its own. The sand falls out on its own.
I can't speak for other parts of the US, but use cases can be subtle and I would be slightly cautious about deciding that 300M people and a several trillion dollar market has been completely irrational for decades.
Alaska checking in. Nobody is hauling a skidoo around here in a van. You also won’t see anyone towing a trailer with one or two machines with anything other than a truck, because nothing else is going to hack it in the mountains with all that. I currently just drive mine up a ramp into the truck bed, I can quickly park and get off and go and back on again. Very versatile combo to get around with.
Right tool for the job. I drive an AWD Prius with winter tires to get groceries in the snow.
It’s the same here in Fairbanks. We also have an Outback that we drove here when we moved a decade ago (towing a trailer, no less). That and the Prius both handle fabulously with winter tires. Since I only use the truck for hauling, it’s always weighted in the back!
The majority of the cost in a database is often serializing/deserializing data. By using IDB from JS, we delegate that to the browser's highly optimized native code. The data goes from JS vals to binary serialization in one hop.
If we were to use OPFS, we would instead have to do that marshaling ourselves in JS. JS is much slower that native code, so the resulting impl would probably be a lot slower.
We could attempt to move that code into Rust/C++ via WASM, but then we have a different problem: we have to marshal between JS types and native types first, before writing to OPFS. So there are now two hops: JS -> C++ -> OPFS.
We have actually explored this in a previous version of Replicache and it was much slower. The marshalling btwn JS and WASM killed it. That's why Replicache has the design it does.
I don't personally think we can do this well until WASM and JS can share objects directly, without copies.
> 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:
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.
I think this is a fascinating and deep question, that I ponder often.
I don't feel like I know all the answers, but as the creator of Replicache and Zero here is why I feel a pull to the web and not mobile:
- All the normal reasons the web is great – short feedback loop, no gatekeepers, etc. I just prefer to build for the web.
- The web is where desktop/productivity software happens. I want productivity software that is instant. The web has many, many advantages and is the undisputed home of desktop software now, but ever since we went to the web the interaction performance has tanked. The reason is because all software (including desktop) is client/server now and the latency shows up all over the place. I want to fix that, in particular.
- These systems require deep smarts on the client – they are essentially distributed databases, and they need to run that engine client-side. So there is the question of what language to implement in. You would think that C++/Rust -> WASM would be obvious but there are really significant downsides that pull people to doing more and more in the client's native language. So you often feel like you need to choose one of those native languages to start with. JS has the most reach. It's most at home on the desktop web, but it also reaches mobile via RN.
- For the same reason as prev, the complex productivity apps that are often targeted by sync engines are often themselves written using mainly web tech on mobile. Because they are complex client-side systems and they need to pick a single impl language.
> Using Zero is another option, it has many similarities to Electric, while also directly supporting mutations.
The core differentiator of Zero is actually query-driven sync. We apparently need to make this more clear.
You build your app out of queries. You don't have to decide or configure what to sync up front. You can sync as much, or as little as you want, just by deciding which queries to run.
If Zero does not have the data that it needs on the client, queries automatically fall back to the server. Then that data is synced, and available for next query.
This ends up being really useful for:
- Any reasonably sized app. You can't sync all data to client.
- Fast startup. Most apps have publicly visible views that they want to load fast.
- Permissions. Zero doesn't require you to express your permissions in some separate system, you just use queries.
So the experience of using Zero is actually much closer to a reactive db, something like Convex or RethinkDB ().
Except that it uses standard Postgres, and you also get the instant interactions of a sync engine.
At the end of the day people have to care about their job, for a reason bigger than getting a paycheck. Society can coast for awhile when people don't care but things eventually break down.
You can add process but the people running the process have to care. You can add regulation, but then the regulators have to care.
At the end of the day people have to care. And it really has to be everyone, because if one group cares and another doesn't, the one that cares will soon get disillusioned.
Caring alone is not sufficient. You do need process to catch mistakes. But process alone is also not sufficient.
I am confused by this question. Both noms and dolt, and presumably most other prolly tree implementations do what you propose. if they didn't, inserts would be terribly slow.
The question is if I'm preparing a meal that I want to be filling, healthy, and energizing, how should I do it. Broccoli isn't a good answer to the protein part of that question.
reply