Interaktives Lernen mit Yjs

 (learn.yjs.dev)
1 Punkte von GN⁺ 2025-01-18 | 1 Kommentare | Auf WhatsApp teilen
  • learn.yjs.dev ist derzeit vorübergehend pausiert, sodass die Lerninhalte nicht eingesehen werden können
  • Auf der Seite wird außer dem Status This deployment is temporarily paused kein Grund für die Pause genannt
  • Ein Zeitpunkt oder Zeitplan für die Wiederaufnahme der Bereitstellung wurde ebenfalls nicht veröffentlicht
  • Aufbau, Funktionen und Beispiele der Yjs-Lerninhalte können auf der aktuellen Seite nicht eingesehen werden
  • Derzeit lässt sich nur feststellen, dass sich learn.yjs.dev in einem vorübergehend pausierten Zustand befindet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-18
Hacker-News-Meinungen

  • Hey HN! Ich bin Entwickler bei Jamsocket und habe das hier gebaut. Falls euch Yjs nicht vertraut ist: Man kann es sich als CRDT-Bibliothek zum Bauen kollaborativer und local-first Apps vorstellen.
    Wenn man noch nie mit verteiltem Zustand gearbeitet hat, ist die Lernkurve ziemlich steil, und selbst ein Counter-Increment wie im „Hello World“ einer JavaScript-Framework-Demo wird knifflig, sobald mehrere Clients beteiligt sind.
    Viele Tutorials laufen nach dem Muster „Installiere diese Bibliothek und die Texteditor-Integration, dann ist die App fertig“ und vermitteln kein mentales Modell dafür, was tatsächlich passiert.
    Deshalb habe ich Learn Yjs gebaut, ein interaktives Yjs-Tutorial, und viele erkundbare Demos und Coding-Übungen eingebaut, damit auch Leute, die local-first Entwicklung neu kennenlernen, es intuitiv verstehen.

    • Ich war an CRDTs und Kollaborationsfunktionen interessiert, aber die größte Einstiegshürde waren jedes Mal genau diese Tutorials nach dem Motto „Bibliothek installieren, fertig“.
      Auch für WebSocket schien es etwas schwieriger, kostenloses Hosting zu finden, und die bestehenden CRDT-Tutorials waren ebenfalls eine große Hilfe.
    • Ich frage mich, ob es Beispiele für das Bauen local-first Apps gibt.
      Ich arbeite mit reinem HTML/JS und Alpine und möchte wissen, ob man Yjs auch in solchen Apps verwenden kann.
    • Ich frage mich, ob das auch mit Yrs [0] funktioniert oder ob es ein separates Projekt ist.
      Außerdem möchte ich wissen, ob Y-Sweet auch mit anderen CRDT-Bibliotheken wie Automerge oder Loro funktioniert oder nur für Yjs gedacht ist.
      Da sie alle eine ähnliche Struktur zu haben scheinen, bei der Binärdateien hin- und hergeschickt werden, war ich neugierig, wie kompatibel Y-Sweet mit ähnlichen CRDT-Implementierungen ist.
      [0] https://github.com/y-crdt/y-crdt
    • Wirklich gut gemacht. Ich frage mich, ob ich damit CRDTs endlich verstehen werde, und plane, es am Wochenende komplett durchzugehen.

  • Yjs ist gut, und P2P-Ergebnisse sind leicht zu erzielen.
    Allerdings wirken ein Yjs-Backend, Persistenz, letztendliche Konfliktlösung (wenn ein Editor zu lange offline war) und das Zurückspulen der Historie wie schwierige Engineering-Aufgaben.
    Ich wollte schon immer eine gute Erfahrung in einem Block-Editor wie Platejs https://platejs.org/ haben.
    Lösungen wie Liveblocks https://liveblocks.io/text-editor versuchen zwar erfreulicherweise, die Developer Experience zu vereinfachen, aber in den meisten Fällen muss man einen Teil der Datenkontrolle abgeben.
    Wenn man auf HN nach dem Stichwort CRDT sucht, findet man immer gute Ergebnisse und Interesse, aber auf der Open-Source-Backend-Seite habe ich kaum gute Optionen gesehen. Ich habe das in der Vergangenheit mehrfach geprüft; falls ich etwas übersehen habe, sagt gern Bescheid.
    https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...
    Die meisten erwarten mindestens ein Verhalten wie bei Google Docs oder Notion, und aus Entwicklersicht möchte man, dass es privat in einem Format ähnlich Postgres JSONB gespeichert wird, ohne tief in die Implementierungsdetails einzutauchen.

    • Theoretisch müsste man nur serialisierte Patches verteilen, aber in einem echten Backend muss man möglicherweise auch den aktuellen Dokumentzustand, die Benutzeridentität und ein gewisses Maß an Zugriffskontrolle kennen.
      Ich wollte Y.js mehrmals in einem Go-Backend verwenden, fand aber keine einfache Referenzimplementierung und habe es wegen Zeitbeschränkungen jedes Mal aufgegeben.
      Auch nach mehreren Jahren sieht es außerhalb von Node.js immer noch schwierig aus.

  • Ich habe Yjs früher in einem kleinen Side Project verwendet. Auf der Client-Seite war es recht leicht zu lernen und zu nutzen.
    Auf der Serverseite wollte ich es als einzelnes Binary deployen, aber Beispiele in anderen Sprachen als Node, etwa für den Rust-Port Yrs, gab es praktisch nicht.
    Am Ende habe ich https://github.com/yjs/y-websocket leicht modifiziert und LevelDB-basierte Persistenz hinzugefügt, aber nach meinem Maßstab war das nicht optimal.
    Ich frage mich, ob es gute Ressourcen gibt, um die Serverseite inklusive Persistenz in einer Sprache wie Rust zu implementieren.
    Soweit ich mich erinnere, waren die vorhandenen Client-Materialien stark auf Texteditor-Integrationen ausgerichtet, daher ist dieses Tutorial wirklich nützlich. Da ich keine Texteditor-Integration verwendet habe, musste ich mich selbst herantasten.

    • Y-Sweet[1] könnte passen. Das ist der Open-Source-Rust-Server, der das Banner von Learn Yjs betreibt.
      Er nutzt S3 oder das lokale Dateisystem als Storage und wird zu einem musl-gelinkten Binary von ein paar MB kompiliert.
      https://github.com/jamsocket/y-sweet

  • Es heißt, es sei eine Technik des Fractional Indexing, „bei der Indizes nicht als ganze Zahlen, sondern als Brüche geführt werden“. Ich frage mich, wie oft man sie verwenden können muss, bevor es stoppt.

    • Ich habe es selbst getestet: Es waren 1075 Mal, und das ist kein besonders großer Wert, daher könnte es ein Hauptproblem dieser Bibliothek sein.
      Der Testcode sieht so aus:
      let left = 0, right = 1
      let rightPrevious = 2
      let counter = 0;
      while (right > left && right < rightPrevious) {
      rightPrevious = right;
      right /= 2;
      counter++
      }
      console.log(counter)
      Ich habe nur sehr kurz ins Repository geschaut, konnte aber nicht finden, wo dieses Problem behandelt wird, und hatte keine Zeit, tiefer einzusteigen. Falls es ein echtes Issue ist, könnte ich bei der Lösung helfen.

  • Ich verwende Yjs gerade beim Bauen einer App, die Offline-Funktionalität braucht.
    Eigentlich ist es keine Echtzeit-Kollaborations-App, aber wenn man den Server als einen Kollaborator und die App als einen anderen Kollaborator betrachtet, kann man sich die Anwendungsfälle leicht vorstellen.

  • Der Punkt, über den ich bei Yjs letztlich nie hinausgekommen bin, ist, dass es viel zu schnell kompliziert wird, wenn man das Beispiel aus diesem Tutorial zum Verschieben von Einträgen in einer Todo-App verallgemeinert.
    Wenn man mehrere Objekte hat, die miteinander in Beziehung stehen, möchte man sie in dasselbe Document packen, und beim Synchronhalten dieser Beziehungen gibt es viele Fallstricke wie das Fractional Indexing im Tutorial.
    Wenn sich dann Einträge in Datenbankgröße ansammeln, bedeutet das Spielzeugmodell, alles in ein einziges Dokument zu stecken, dass man jedem, der irgendeinen Eintrag lesen will, die gesamte DB samt ihrer Historie schicken muss.
    Am Ende muss man die Einträge in separate Objekte aufteilen und selbst persistieren, aber außer diesem Tutorial [0] gibt es keine Dokumentation dazu; Spoiler: Es ist eine leere Seite, auf der seit Jahren „Work in Progress - come back later“ steht.
    Selbst wenn man also einen Provider bauen und verwalten will, ist die Dokumentationslage dieselbe [1].
    Man entdeckt Subdocuments und freut sich, dass es vielleicht eine Lösung für dieses häufige Problem gibt [2], aber manche Provider können Beziehungen zwischen Subdocuments nicht verarbeiten, und manche unterstützen Subdocuments selbst gar nicht. Am Ende muss man also doch selbst einen Provider schreiben und landet wieder beim Problem der fehlenden Dokumentation.
    Wenn man versucht, den Code zu lesen, merkt man schließlich, dass der Kern von Yjs das Protokoll ist. Aber auch dieses Protokoll, also das eigentliche Wesen von Yjs, ist nicht vollständig dokumentiert und über mehrere ziemlich eigenwillige Codestellen verstreut. Es sei denn, man zählt ein Paper darüber, wie der Vorläufer von Yjs vor zehn Jahren funktionierte, als Dokumentation.
    Das sollte eigentlich keine Beschwerde werden, aber ich habe über Jahre viel zu viel Zeit damit verbracht, es zum Laufen zu bringen, und die Lücke zwischen „funktioniert wie Magie!“-Spielzeugdemos und etwas Realem ist riesig. Die Dokumentation zu diesem Teil war zehn Jahre lang außer „Work in Progress“ leer.
    Ich hoffe, dass Unternehmen, die wie der Autor dieses Beitrags versuchen, mit Yjs Geld zu verdienen, diese Lücke schließen.
    [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] Ich hatte beim Schreiben gehofft, dass sich die Lage geändert hat, aber die gesamte Dokumentation ist offenbar immer noch wie vor fünf Jahren in Arbeit, und bei der Unterstützung für Subdocuments sieht es genauso aus.

  • In der interaktiven Demo war ich irritiert, dass der Latenz-Slider nicht wie Netzwerklatenz, sondern eher wie ein Debounce-Puffer funktioniert. Ich verstehe nicht, warum das so gemacht wurde.

    • Es wurde das einfachste Verzögerungsmodell gewählt, das ausreicht, um die Probleme zu zeigen, die entstehen, wenn sich Zustand an mehreren Stellen ändert.
      Der Vorteil dieser Methode ist, dass sie implementiert werden kann, ohne dem Leser irgendeinen Zustand zu verbergen. Das Tortendiagramm zeigt den einzigen vorhandenen internen Zustand direkt an.
      Ziel ist keine exakte Netzwerksimulation, sondern der Aufbau von Intuition.

  • Die interaktive Demo ist wunderschön. Mich würde interessieren, welche Libraries dafür verwendet wurden.

    • Die gesamte Site wurde mit Astro gebaut, und die Demos sind „Interaktionsinseln“ in React.
      Die Demos lassen intern tatsächlich Yjs laufen. Jeder „Client“ hat sein eigenes Dokument, und wenn der Nutzer klickt, wird per setTimeout eine Verzögerung simuliert; anschließend werden die Dokumente manuell miteinander gemerged. Außerdem gibt es ein drittes Dokument für die Timeline in der Mitte.
      Darüber hinaus werden dnd kit [1] für Drag-and-drop in der Todo-Demo, Motion [2] für Animationen und CodeMirror [3] für den Texteditor verwendet.
      [1] https://dndkit.com
      [2] https://motion.dev
      [3] https://codemirror.net

  • Das Spiel im Bannerbild ist albern, aber macht Spaß.

  • Ich hatte endlich ein vierblättriges Kleeblatt gebaut, aber nach etwa zwei Minuten hat es jemand kaputtgemacht.
    Edit: Moment, wo sind alle hin? Entweder haben wir es kaputtgemacht, oder ich wurde geblockt. Trotzdem Applaus an die Person, die das gebaut hat. Ein cooles Ding.

    • Geblockt bist du ziemlich sicher nicht. Es sieht so aus, als wären kurz weniger Leute da gewesen, und jetzt sehe ich wieder ziemlich viele Cursor.
      Übrigens gibt es noch zwei weitere geheime Emojis.