HN Reader

Hey HN! I'm the developer at Jamsocket who made this. In case you're not familiar with Yjs, it's a CRDT library for building collaborative and local-first apps.

The thing is, if you're not used to working with distributed state there's definitely a learning curve. Even simple things like incrementing a counter — the "hello world" of JavaScript framework demos — get tricky when dealing with multiple clients. Worse, a lot of tutorials are just like "install this library and text editor integration and boom you have an app", which doesn't give you a good mental model for what's actually happening.

So we made Learn Yjs! It's an interactive Yjs tutorial. I wanted it to be really intuitive for people just getting their feet wet with local-first development, so there are lots of explorable demos and coding exercises. The idea is to use interactive examples to build an understanding from the ground up.

Hope you like it :)

another banger from the jamsocket team

The interactive demos are beautiful! Is there a library you used to build it?

is Yjs a platform like Convex? are they competing? would love a comparison page potentially! :pray:

I used Yjs in a small side project a while ago. The client side was fairly easy to learn and use. On the server side though, I wanted to deploy a single binary, but examples in languages other than Node (e.g. for the Rust port Yrs) seemed close to nonexistent, so I ended up slightly adapting https://github.com/yjs/y-websocket (Node) with persistence based on LevelDB. That's suboptimal for me. I wonder if there are good resources for implementing the server-side with persistence in, say, Rust.

Btw, IIRC existing resources for the client side are heavily focused on text editor integrations, so this is really helpful. I had to fumble a bit myself because I wasn't using a text editor integration.

Yjs is nice. Easy to get p2p results.

Yjs backend, its persistence, eventual conflict resolution (one of editors stayed too long offline), history rewind seems like a tough engineering challenge to crack.

Always wanted to have a nice experience with block editor like Platejs https://platejs.org/

There are nice attempts simplify dev experience with solutions like Liveblocks https://liveblocks.io/text-editor However most options come at the expense of controlling your data.

CRDT keyword search on HN bring consistently good results and interest in the topic, but no good options on open source backend side. Checked it many times in the past. Please correct me if I missed something.

https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...

Most people expectations it should work at least as in Google Docs or Notion, and on the dev side it should be store privately in Postgres JSONB like format without going deep into details.

I finally got a four leaf clover and somebody ruined it after like 2m.

Edit: Wait, where did everybody go? I think we broke it, or maybe I got banned. Kudos to the creator just the same. Neat stuff.

I'm currently using Yjs to build an app that needs to work offline. It's not actually a real-time or collaborative app. However, if you think of the server as being one collaborator and the app being another, then it's easy to imagine use cases for it.

So perplexing - in the interactive demos, the latency slider acts not as a network latency but more a debounce buffer? Why? Why? I just don't get it

> The trick is a technique called fractional indexing, in which indices are fractions rather than integers.

How many times you can use fractional indexing before it stops working?

The banner image game is silly but fun

The thing I never got past with yjs was that the generalization of the todo app item-moving thing in this tutorial gets messy so quickly. If you have multiple objects that relate to each other, then you want them in the same Document, and keeping the relationships in sync has lots of gotchas (like needing the fractional indexing in the tutorial).

But then you accumulate a database worth of items and the simple toy model of putting everything into one document amounts to having to ship the whole DB (and it's history) to anything that wants to read any items. So you need to start breaking the items into separate objects and persisting them yourself, which has no documentation except for this tutorial [0] (spoiler alert: it's just an empty "Work in Progress - come back later" and has said that for years and years and years).

So you try to build a Provider to manage things, and the documentation story is the same [1].

Then you find out about Subdocuments and get happy that there's a solution to this common problem [2], but then learn that some Providers can't handle any relationships between subdocuments, and some Providers don't even support subdocuments, which goes back to issue of DIY providers not being documented.

So then you try to read some code to learn about it (after all, it's open source, we can't expect the dev to do all the work for us for free; let's do some work too!) and realize that what yjs really is at its core is a protocol. And that protocol -- the very essence of yjs -- is also totally undocumented and spread across a bunch of relatively idiosyncratic code. Unless you count a paper that documents how a yjs precursor worked a decade ago.

I didn't intend this to turn into a rant, but I've spent so much time trying to get it working over the years, and the gap between the toy 'Look it's magic!' demos and anything real is just so wide and the documentation for that part has been empty except "Work in Progress" for a decade.

I'm hopeful that some of the companies trying to monetize yjs, like the author of this post, are willing to step into that gap (which is who I'm writing this for, btw).

[0] https://docs.yjs.dev/tutorials/persisting-the-document-to-a-...

[1] https://docs.yjs.dev/tutorials/creating-a-custom-provider

[2] https://docs.yjs.dev/api/subdocuments

[3] I was really hoping that as I wrote this, the situation has changed, but it looks like all the documentation is just as WIP as five years ago and same for subdocument support.