41–50 of 73 posts
A 225K gzipped .wasm file download for a client-side state management and persisistence layer is not great. It is competitive with some similar solutions, but still a lot for any web app's performance budget
What about conflict resolution? If two users update the same record/field around the same time? Isn’t that the trickiest part of real time?
I'm really glad to see an article like this. I've worked in the space for a while (Fluid Framework) and there's a growing number of libraries addressing realtime collab. One of the key things that many folks miss is that building a collaborative app with real time coauthoring is tricky. Setting up a websocket and hoping for the best won't work. The libraries are also not functionally equivalent. Some use OT, some use…
Built a Google Docs like rich text collaborator for a client on Express/Psql and React. Worked like a charm. The hardest part was dealing with ports on AWS to be honest.
It never really took off in the mainstream - I think because it was before many developers really trusted JS on the server, and a "full stack" framework is quite a big commitment for a team to shift to. Also most CRUD apps don't need real time collab.
I remember being amazed when changes were instantly propagated between my phone and laptop browsers with almost zero lag. This was the demo that sold it for me https://www.youtube.com/watch?v=MGbmW9bwJh4
Earlier quoted context omitted.
That's what Replicache[0] solves, it provides for Causal+ Consistency across the entire system. "This means that transactions are guaranteed to be applied atomically, in the same order, across all clients. Further, all clients will see an order of transactions that is compatible with causal history. Basically: all clients will end up seeing the same thing, and you're not going to have any weirdly reordered or dropped…
It appears Replicache doesn't use CRDTs since it has a central source of truth: https://news.ycombinator.com/item?id=22175530 See also the commentary here: https://doc.replicache.dev/guide/local-mutations This sounds a lot like Operational Transform but without the transform part - it assumes that locally applied mutations can be undone and rebased without user interaction. But I feel like the Google Wave team would…
Now, it is true that OT is considered the gold standard for certain kinds of collaborative editing, in particular unstructured text. But CRDTs are quickly catching up and I believe that any CRDT should by definition be implementable on top of Replicache.
Its also quite a lot easier to implement a Replicache backend than an ot backend.
I'm really glad to see an article like this. I've worked in the space for a while (Fluid Framework) and there's a growing number of libraries addressing realtime collab. One of the key things that many folks miss is that building a collaborative app with real time coauthoring is tricky. Setting up a websocket and hoping for the best won't work. The libraries are also not functionally equivalent. Some use OT, some use…
PouchDB+CouchDB work well out of the box with minimal fuss for open pieces you can just plug into this role. PouchDB handles the client's state persist and replication on the client, couchdb is the reliable cloud service you can replicate to.
Meteor, at least their pre-apollo stack had realtime collab type features with their mini-mongo client and oplog tailing.
Earlier quoted context omitted.
You probably don't want to use Automerge. See https://josephg.com/blog/crdts-go-brrr/ for a nice CRDT optimization story.
Interesting! I know there was a large performance refactor that was merged in May [0]. This post you link was written in June of this year. Unclear if the performance fix is related to the reported issues and unsure if it still exists or not. At the very least, the automerge maintainers seem to be very actively tackling performance problems. [0] https://github.com/automerge/automerge/pull/253
They’re working on it, but it’ll be awhile before automerge gets close to Yjs in terms of performance.
Earlier quoted context omitted.
It appears Replicache doesn't use CRDTs since it has a central source of truth: https://news.ycombinator.com/item?id=22175530 See also the commentary here: https://doc.replicache.dev/guide/local-mutations This sounds a lot like Operational Transform but without the transform part - it assumes that locally applied mutations can be undone and rebased without user interaction. But I feel like the Google Wave team would…
I’m not sure if you are understanding that when Replicache rebases operations locally it actually re-executes code which can have arbitrary effects. This design yields a lot of flexibility to preserve intent: the function can look at current state of world and decide to do something different. Now, it is true that OT is considered the gold standard for certain kinds of collaborative editing, in particular unstructure…
The result is we need way less complexity in the browser, or in applications. And still get all the advantages crdts bring - namely, no need for a central server acting as the source of truth.
I haven't yet done this but based on some research it seems to me like the core of any collaborative app today (that wants to avoid Firebase and the other hosted platforms like Replicache seems to be) is easiest served by picking some CRDT library. There are a couple of open-source CRDT libraries that provide both clients and servers (yjs [0] and automerge [1] are two big ones for JavaScript I'm aware of). My basic a…
web apps are sorely lacking a core storage technology
whoever gets their first may not make a lot of money but they'll be more influential than react (because the schema design will penetrate native dev as well)