guillaumesalles

By "other use cases", are you talking about apps that are not design tools like Notion or Google Spreadsheet? Or other edge cases related to undo/redo?

To summarize the differences between Ably/Pusher and Liveblocks, Ably/Pusher use a centralized Redis to broadcast messages to channels. Liveblocks has tiny isolated servers on the edge for every room. These two different architectures create the following trade-offs:

- Ably/Pusher are lower level than Liveblocks. It doesn't have any storage associated to a channel and does not solve any conflicts.

- Liveblocks provides API to migrate existing app into collaborative ones via integration with state management library like Redux/Zustand. I have a POC somewhere that try integrate with Vuex, would love to release that at some point!

- Ably/Pusher charges per WebSocket message sent. Liveblocks charges per WebSocket connection. Because of that, building features like cursors can become quite expensive on Pusher.

- Ably/Pusher lets you connect to multiple channels with a single WebSocket connection (because they're using a centralized Redis IIRC). Liveblocks requires a single WebSocket connection per room. Pusher is good for notifications systems, Liveblocks shines when you need to build an app like Figma or Google spreadsheet.

Hope it helps!

Our code client does not depend on any front-end technology, so you can use it with Svelte or Vue. We have a few examples that use Vue and Svelte here: https://github.com/liveblocks/liveblocks/tree/main/examples

Our most advanced Svelte example is this one : https://pixelart.liveblocks.app/

If there is enough demand, we'll make an official wrapper for Vue and Svelte!

If you're looking for WebSocket without all the state synchronization we provide, there are a few well-known providers like Ably or Pusher.

For rich text editing, undo should probably reset the scroll position and the cursor close the edit you're undoing.

I think reseting the time position would also make sense for video editing.

So basically, it's a way to get back as much as possible in the context you were at the time of the operation that is undone.

Yes that's good way to implement it!

But I'm still not sure this is the default behavior that we want, even it's only for deletion. I think it's more of a UX problem than an engineering problem as explained here: https://news.ycombinator.com/item?id=31682073

To take another example, for rich text editing, I don't think undoing a formatting operation on text that has been deleted at the same time should reinsert the text.

Yes! We're using Durable Object under the hood :) Thanks to you for providing such a great platform!

It's technically possible by caching only deleted shapes if any operations in the undo stack are associated with them. But is it really the UX we want every time it's happening?

Let's imagine that we work together on a design file that contains hundreds of icons. I'm responsible for adjusting the color palette while you're removing the old icons that are not used anymore. If I undo my last color update on all icons, I probably don't want to recreate the icon inadvertently and override the triage you're doing! So IMO, it's more of UX question than a technical question. Is there a better default solution that we can find to improve these edge cases? My initial thought is to have a small "toast" letting the user know that the undo operation couldn't be applied because X does not exist anymore, with a link to the version history panel to allow him to reinsert X if it wants to.

I worked on the implementation so don't hesitate if you have deeper technical questions that the article is not covering :)

Hey CTO and co-founder at Liveblocks here :wave:

Happy to answer any technical questions!

Like Yjs, our Storage block is CRDTs based, but we're making different trade-offs. For example, our CRDTs are not "pure" so we solve some conflicts on the server. Also, we don't support Text CRDTs yet.

But Liveblocks is not just about conflicts resolution! Our vision is to shape our API and guides to help companies transform existing products into collaborative ones. For example, by simply adding live cursors and avatars and refreshing the data with existing REST endpoints, an existing app becomes more collaborative even if the conflict resolution is not perfect. At the same time, we provide analytics on how Liveblocks is used to help product teams prioritize their collaborative features and if they still want to integrate Liveblocks further.

We're also hosting the WebSocket infrastructure and make it scale because we know how troublesome it can be to maintain.

I just answered the Durable Objects question here https://news.ycombinator.com/item?id=27998674

I didn't evaluated fly.io but from their website, it definitely looks promising! I will try it for sure!

Thanks for the kind words :)

Nice catch! All the examples that you see on our website are using Cloudflare Durable Objects! But because they are limited, we also have a version of our server that works on AWS some of our customers.

Good question!

There are still a lot of specialized editors that are not text-based nor collaborative yet.

In the creative space, we can imagine 3D collaborative editors (think Figma but for 3D). Here is an example built with liveblocks: https://liveblocks.io/examples/3d-shoe-builder

Filling a form can also be a collaborative experience: https://liveblocks.io/examples/collaborative-logo-builder

Building a form can also be a collaborative experience! Think Typeform editor with multi-player features.

All the no-code tools could benefit from multi-players feature. Any "data entry" could be collaborative.

For example, we're working with https://cloverapp.co/ to improve their collaborative features (live cursors on whiteboard and live avatars).

I hope it answers your question

Thanks for the kind words :)

From what I understand from Replicache, it focuses only on conflicts resolution with CRDTs, and it does not come with a web socket infrastructure nor a hosted backend. You need to have your own servers or use external services to have live cursors. (https://doc.replicache.dev/guide/poke)

At Liveblocks, we want to bundle all that together because we believe that being tightly integrated is necessary to provide a great experience.

For example, if you implement an "undo"/"redo" feature on a collaborative design tool (like Figma), the selection of a user (volatile state) should be in sync with the document state (persisted state).

Some people might prefer managing their own backend infrastructure, but we want to provide it because we know how difficult it might be to scale and load balance web sockets rooms. We want to help companies focus on their core product and not spend too much time working on the multiplayer infrastructure and algorithms.

From our experience, live cursors positioning depends on the use case and the content behind them.

For a "canvas app" (like Figma), the positioning will be absolute with an offset depending on the panning.

For a responsive website, if it makes sense to add live cursors, it depends on how the content "flows". For example, if your content scrolls vertically and is centered horizontally, you can use percentage on the "x" axis and absolute on the "y" axis. That's what we're doing it in this example: https://liveblocks.io/examples/live-cursors-scrollable-page

Sometimes, cursors are not the best way to show what users are doing on a web page. For a form, displaying an indicator close to the focused input is more valuable.

Because there is no perfect solution, we're not shipping any UI with Liveblocks and only provide guides. In the future, if a common abstraction appears, we will create some package to make the integration easier.

Hi! Great questions :)

Liveblocks does not come with a specific UI. We're providing APIs to create rooms and share states between users. The state can be volatile (like cursors, focused input, selection) or persisted even when the session is over, like a figma file or a google document (this part is still in private beta). We're using custom CRDTs for the persisted state.

We only have a javascript client and react client, but we plan to support more technologies in the future. Even native clients for desktop or mobile if there is an interest.

We have guides to install liveblocks with Next.js, Nuxt.js, and vanilla js + express. https://liveblocks.io/docs#installation

We also have open source repositories with working examples with these technologies.

https://github.com/liveblocks/javascript-examples https://github.com/liveblocks/next-js-examples https://github.com/liveblocks/nuxt-js-examples

Hope it helps! Don't hesitate if you have more questions

Hi Gys, co founder of Liveblocks here!

Our goal is to help companies create collaborative products like Figma or Google Docs with API and guides. Multiplayer infrastructure and conflicts resolutions can be challenging to build in-house and we think it will become a commodity (like logging or analytics systems).

If our marketing video didn't convince you, maybe our examples page and documentation will give you more information.

https://liveblocks.io/examples and https://liveblocks.io/docs