typingmonkey

Does DuckDB support multi tab usage? How big is the wasm file that must be loaded?

I just described the world how it is. I did not create it, I did not made the browser. I do not understand your point. You want to complain about what exactly?

The browser is an abstraction layer. It will always be slower. But all this does not matter because your user will not write 20 chat messages / second.

Yes, this is exactly what is happening. But still you only have one CPU in JavaScript, so the GUI part will take the resources from the database part.

> Syncing that local CouchDB to your web based CouchDB is very fast

This is not true. When you compare the CouchDB replication with other replication protocols, it is slow. The reason is that CouchDB supports replication with many instances at the same time. This creates big overhead in handling revision trees. Many requests have to be made all the time. You can observe that by starting the PouchDB subproject in the comparison repo. Watch the network tab in dev tools. Another problem is that CouchDB does not support Websocket replication, everything is long polling and plain http requests.

Other replications that only support many-clients-to-one-server are way faster. Both, on the initial load and on ongoing changes. This was the main reason why I build GraphQL replication for RxDB.

Replication, Encryption, Conflict Handling, Multi-Tab-Support, Compression, Observability and many more..

I wrote so much things and posted it on HN over the years. There is just no way to make everyone happy, someone always complains that some infos are missing or too much.

I now leave things out that can be googled and are already known by "most" readers.

When you insert 20 messages, there is way more happening than 20 db writes. Each insert will affect the UI which will cause a layout change. Also the changes will be replayed in different browser tabs and might also be replicated to the backend. Then there is things like conflict resolution, validation and encryption. You just cannot compare these speeds with your MySQL insert operation.

Yes RxDB conflict resolution is equal to PouchDBs. At least for now, there are plans to improve from there where you have a global resoluting function instead of listening for conflicts in the changestream.

It is benchmarking the firestore JavaScript library that runs at the client.

Author here.

I am using RxDB with Capacitor (iOS and Android app). You can use the SQLite based pouchdb adapter with capacitor. It keeps your data and is (sometimes) faster.

Here [1] I have documented a whole section about how to use RxDB+SQLite in Capacitor.

[1] https://rxdb.info/adapters.html

I considered to add Supabase, RethinkDB and meteor. But they are not really client side databases. They realtime stream query results from the server to the client.

So the plain data is smaller because some information comes from the schema instead of the object. Guess what, you can do the same with json already [1]

[1] https://github.com/pubkey/jsonschema-key-compression

I would say most browser users do not care about developer tools. They are normal people, they do not debug stuff.

Yes this clarifies it, thank you.

I do not understand this. You have better "desktop CPUs" and want to be 4x faster then github actions? Most of CI time is spend on downloading stuff or moving files, how can this ever be 4x faster with just better CPUs?

> On average it reduces the CI run time by 50% (we forked and tested on ~100 public repos)

So in reality is is just 2x faster on non-optimized public repos?

Yes, most of them. I think the risk by using strike is much less and you do not have to be online to accept payments.

Which is not a good sign for general LN adoption.

If it is an DNS error, why is the .onion site also offline?

- https://en.wikipedia.org/wiki/Facebook_onion_address

- facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion

That gave me a smile :)

Yes, I totally missed this side of the dice. Having your data stored locally, being in control, being able to reset the state to it's origin, export the local state as json and import it somewhere else, knowing what is stored and how long.

Yes. I have written both of them, mostly to make sure I trigger 100% of people, no matter if they like offline first or not.

I mean, read all these comments on both articles. People say offline first does not work, then they say that every software is offline first by default and it is nothing new.

It was totally worth it spending two 3 days on it :)

Same here, they gave me credits 2 weeks after migration to gh actions.

Does having private fields mean we can securely minify them?

Firestore is not really offline-first. Your app wont start without internet connection because the auth handler needs that.

Yes. It can even work fully without any server synchronization. It is just a db in the browser, sync is optional.

You should try RxDB. It is based on pouchdb and therefore supports offline first [1]. Also you can use the graphql replication so that you are not limited to couchdb backend. Also there is a course made by hasura about using RxDB with their backend [2]

disclaimer: I made RxDB

[1] https://github.com/pubkey/rxdb

[2] https://hasura.io/learn/graphql/react-rxdb-offline-first/int...

Yes, indeed an impressive project. I think we should not use the termination "stored at IPFS" like they do. Distributed via IPFS would be much more correct in a technical sense.

Yes I fully understand this. Also with vue2 you often get problems with the internal version of "array" that is wrapper around a normal array to detect changes.

There is a big difference between having a changestream of writes to the database, and observing results of multiple queries.

There are many mobile apps out there which work great and are offline first. For example the whatsapp client. So saying it is "fundamentally flawed" sound weird to me.

I have no deep knowledge of Firebase RTDB so I cannot do any comparison on that point.

Yes and no. Read "realtime" not like "realtime computing" but like a marketing keyword introduced by firebase which means something like live-replication. https://firebase.google.com/docs/database?hl=en