That could be interesting! Curious: are you taking about a plain object spread, or are you talking about JSX spreads? The latter has more overhead. Also, which JS engine?
BTW. I recently measured the spread operator in a microbenchmark. Interestingly, while the native spread was faster on Hermes and JSC, it was slower on V8/Chrome, and it's faster there to use `Object.assign()`, i.e.:
Thanks! There's a preliminary PR with a discussion here: https://github.com/facebook/hermes/pull/933 (and broader context here: https://github.com/facebook/hermes/issues/811 ). But we'll see if there's any interest on Hermes' side to merging it. They definitely want to improve the parser, but it's unclear to me if they want to take on the simdjson/simdutf dependencies.
Browser-based apps have use cases even when you reject PWAs generally as a replacement for native apps. Trying out a new tool quickly, or short-term when using a tool with a customer, in enterprise where you can't install native tools, etc...
IndexedDB is a joke of a database. Yes, it can store data, and you can create a very simple index, so it's _technically_ a database… But its ability to express queries is borderline useless for all but simplest use cases, it's slow, and it's very inconvenient to use. So solutions exist that range from giving IDB a simpler, more modern API, all the way to using IDB as a dumb storage medium to a fast in-memory database.
You can use multiple tabs but to have more than one write to the DB and not be overwritten relies on (online) sync.
The problem is that Watermelon assumes a consistent view of the entire database, so you can't have multiple writers - at least not without synchronous notifications from IndexedDB (not a thing), leader election (cannot be made reliable), or some design sacrifices. To be reconsidered in the future...
IndexedDB is a _bad_ API, and making many small read/write operations on it is absurdly slow. This is one of the reasons why WatermelonDB on web only uses IDB as a dumb storage medium but actually does all the database'y things in memory. You won't reasonably scale to gigabytes this way, but for most PWAs this is plenty enough and MUCH faster in practice. Certainly far faster than network.
not very familiar with apollo, but I don't see why not. But just be aware that Watermelon works best as a full local database copy (that synchronizes with the server), not just a cache.
No, Watermelon is a local app database. But you can plug it into a sync engine to synchronize with the server (and then from the server to another device) — it's up to you
Not familiar with either Gun or Vue. I'll look into the former, and as for the latter — Watermelon does not actually depend on React. If one can supply a way to hook an RxJS observable into Vue (a la higher order components in React), it should work perfectly fine. Pull requests welcome!
I'll be really curious to hear your feedback on GH if you try it. We've been using it internally in dev for a year, but we've just released this as open source, so there's probably a ton to improve on.
A mobile app database. It can probably scale to hundreds of thousands too, but very few apps and very few users of such apps would actually have THAT much data.
The point is that most current solutions for React Native apps start being super slow when you get to 1000s, or have other issues (like using SQLite directly doesn't give you observability)
Yep, if you can support some (relatively basic) queries, and CRUD operations, you can plug in essentially any database, and bridge on any platform. Think Electron, SQLite on native macOS, heck, you could use Realm as the underlying database if you so preferred...