Live data from Hacker News

A simple way to build collaborative web apps

zjy.cloud

71–73 of 73 posts

Re: A simple way to build collaborative web apps

#71
post #51

Earlier quoted context omitted.

The release build is 100k brotli I believe. It’s possible this site is using the dev binary.

It uses the production binary, originally 604.59 KB and after brotli (Vercel uses brotli by default) 213.90 KB.

Ah, when I brotli compress it locally, it's 188 (which is where I remembered 100 from) but I guess it uses different settings than the auto-brotli in Vercel.

Re: A simple way to build collaborative web apps

#72
post #33

Earlier quoted context omitted.

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.

Ah, that's a shame. Good to know, thanks.

Re: A simple way to build collaborative web apps

#73
post #48

Earlier quoted context omitted.

I don’t know enough to comment on replicache, but you can also do OT on top of an operation based CRDT. For diamond types we’re making it support both - so if you want to, applications can do OT (which is simple, small, and fast) to talk to a server (or local proxy process), and then that process can do p2p server to server replication using CRDTs. The result is we need way less complexity in the browser, or in appli…

Cool, I need to look into this more. I think for many customers the authoritative server is an advantage. It's useful in SaaS apps for the server to be able to override the clients, for all kinds of reasons -- antiabuse, authorization, extra validation rules, or just fixing bugs.

Yes, I completely agree. And I think we want both:

- A fast and well written CRDT that works in p2p networks should also work great for server-to-server replication in a data center (or across data centers).

- OT algorithms designed to work with centralized servers are simple, efficient, easy to code up and easy to work with. And they provide a really nice API for local applications to do IPC. CRDT libraries can expose OT endpoints just fine.

I'm still not 100% sure about what the best approach is in the P2P case. Embedding (/ linking) a CRDT library into every application would also work fine, but its complicated to get everything working across languages. And harder to update. The other option is running a single system / applicatoin wide CRDT-like service which manages credentials, that applications talk to like LSP / D-Bus. In that case, applications can just talk OT (which is much simpler).

Either approach would work.

Post reply on HN