Live data from Hacker News

A simple way to build collaborative web apps

zjy.cloud

31–40 of 73 posts

Re: A simple way to build collaborative web apps

#31

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…

Fluid Framework looks pretty cool! I somehow missed the Build announcement about this.

Maybe it's just me, but it has a SignalR + Orleans sort of vibe to it when I think about the types of problems it solves. I will definitely be digging into this a bit more.

Re: A simple way to build collaborative web apps

#32
I remember listening to an episode of the Exponent podcast, in which Ben Thompson said something like (paraphrasing from memory):

> People who love "native apps" can complain about Electron all they want—but there's simply no replacement for the real-time collaboration offered by web-based apps like Figma!

As someone who's not exactly thrilled with Electron and its memory usage—is there a reason the two go together? Is there a reason we can't build collaborative apps in Cocoa and GTK? I think these systems are awesome, I just think they'd be even better if they weren't also running full web browsers!

Re: A simple way to build collaborative web apps

#33

I remember listening to an episode of the Exponent podcast, in which Ben Thompson said something like (paraphrasing from memory): > People who love "native apps" can complain about Electron all they want—but there's simply no replacement for the real-time collaboration offered by web-based apps like Figma! As someone who's not exactly thrilled with Electron and its memory usage—is there a reason the two go together?…

Figma’s performance is excellent due in large part to the fact they compile a lot of native code to Wasm. Electron or not it’s still fast.

To answer your question, collaborative apps ideally need to target the widest possible audience. Barring a massive budget, the best way to accomplish this is to also have a singular compile/build target. In most cases, that’s the web platform.

Re: A simple way to build collaborative web apps

#34
You could build this with couchdb multi master regional servers and pouchdb on the client and have full consistency with the replication both to clients and servers as well as conflict resolution (in case of collision) done for you.

This route seems like a lot of extra work for pretty similar functionality.

Re: A simple way to build collaborative web apps

#35
post #17

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…

Indeed, there can never be one universal solution to this, because the problem is one of specification rather than (only) implementation. For example, suppose we have an edit/delete conflict, where two clients concurrently interact with the same entity in your data model. In a simple case, we can decide to “resurrect” the affected entity and apply the edit, which is the option that never results in significant data l…

The good old CAP theorem hits again...

Re: A simple way to build collaborative web apps

#36

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…

> is easiest served by picking some CRDT library.

RDBMS A.C.I.D. and transactions are also capable of much of the same.

Re: A simple way to build collaborative web apps

#37
post #3
post #2

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?

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…

How one wants to see them could depend; that's why I recommend using an RDBMS. One can "play back" transactions using different orders and filters. If teams get confused or accidentally "step on each others toes", then one may need to review different scenarios to see what was intended by two or more parties.

Re: A simple way to build collaborative web apps

#38

I remember listening to an episode of the Exponent podcast, in which Ben Thompson said something like (paraphrasing from memory): > People who love "native apps" can complain about Electron all they want—but there's simply no replacement for the real-time collaboration offered by web-based apps like Figma! As someone who's not exactly thrilled with Electron and its memory usage—is there a reason the two go together?…

It could totally be done natively. The obstacle is how much of the stack you have to write and maintain. There are js libraries that do most of this heavy lifting for you, and CRDTs are pretty new to most devs.

It's just much much easier and cost effective to build a single code base and hit many many targets platforms with it.

Computing history has also shown that publishing efficient lean software doesn't help in the market. At least not over time to market, getting the key features right, and your ongoing costs.

Re: A simple way to build collaborative web apps

#40
post #33

I remember listening to an episode of the Exponent podcast, in which Ben Thompson said something like (paraphrasing from memory): > People who love "native apps" can complain about Electron all they want—but there's simply no replacement for the real-time collaboration offered by web-based apps like Figma! As someone who's not exactly thrilled with Electron and its memory usage—is there a reason the two go together?…

Figma’s performance is excellent due in large part to the fact they compile a lot of native code to Wasm. Electron or not it’s still fast. To answer your question, collaborative apps ideally need to target the widest possible audience. Barring a massive budget, the best way to accomplish this is to also have a singular compile/build target. In most cases, that’s the web platform.

Figma's performance is impressive for an Electron app, but it does choke on very large files, which Sketch would have handled without a care. It's not great.

If Sketch had had Figma's collaboration features, we wouldn't have switched. But during the pandemic it was necessary.

Post reply on HN