Aprendizaje interactivo con Yjs

 (learn.yjs.dev)
1 puntos por GN⁺ 2025-01-18 | 1 comentarios | Compartir por WhatsApp
  • learn.yjs.dev tiene actualmente el despliegue en pausa temporal, por lo que no es posible revisar el contenido de aprendizaje
  • En la página, aparte del estado This deployment is temporarily paused, no se indica la causa de la pausa
  • Tampoco se ha publicado una fecha o calendario para la reanudación del despliegue
  • La estructura, funciones y ejemplos del contenido de aprendizaje de Yjs no pueden revisarse actualmente en la página
  • Por ahora, lo único que puede afirmarse es que learn.yjs.dev está en estado de pausa temporal

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-18
Opiniones de Hacker News

  • ¡Hey HN! Soy desarrollador de Jamsocket, que creó esto. Si no conoces Yjs, puedes verlo como una biblioteca CRDT para crear apps colaborativas y local-first.
    Si nunca has trabajado con estado distribuido, la curva de aprendizaje es considerable, e incluso incrementar un contador, el “hello world” de las demos de frameworks JavaScript, se vuelve complicado cuando intervienen varios clientes.
    Muchos tutoriales son del tipo “instala esta biblioteca y la integración con un editor de texto, y listo, app terminada”, así que no te dan un modelo mental de lo que realmente está pasando.
    Por eso creamos Learn Yjs, un tutorial interactivo de Yjs, con muchas demos explorables y ejercicios de programación para que incluso quienes se acercan por primera vez al desarrollo local-first puedan entenderlo de forma intuitiva.

    • Me interesaban los CRDT y las funciones colaborativas, pero cada vez que intentaba empezar, la mayor barrera eran justamente esos tutoriales de “instalas la biblioteca y ya”.
      También parece un poco más difícil encontrar hosting gratuito para WebSocket, y los tutoriales existentes de CRDT tampoco me ayudaron mucho.
    • Me pregunto si hay ejemplos de cómo crear apps local-first.
      Estoy trabajando con HTML/JS puro y Alpine, y también quisiera saber si Yjs se puede usar en apps así.
    • Me pregunto si esto también funciona con Yrs [0], o si es un proyecto separado.
      También quisiera saber si Y-Sweet funciona con otras bibliotecas CRDT como Automerge o Loro, o si es solo para Yjs.
      Como todas parecen tener una estructura similar de intercambiar archivos binarios, me dio curiosidad qué tan compatible es Y-Sweet con implementaciones CRDT parecidas.
      [0] https://github.com/y-crdt/y-crdt
    • Está muy bien hecho. Me pregunto si con esto por fin podré entender los CRDT, y planeo verlo completo el fin de semana.

  • Yjs es bueno, y es fácil obtener resultados P2P.
    Sin embargo, el backend de Yjs, la persistencia, la resolución final de conflictos (cuando un editor estuvo demasiado tiempo offline) y rebobinar el historial parecen ser problemas de ingeniería difíciles de resolver.
    Siempre quise una buena experiencia en editores por bloques como Platejs https://platejs.org/.
    Está bien que soluciones como Liveblocks https://liveblocks.io/text-editor intenten simplificar la experiencia de desarrollo, pero en la mayoría de los casos hay que ceder parte del control sobre los datos.
    Al buscar la palabra clave CRDT en HN siempre aparecen buenos resultados e interés, pero en el lado de backends open source no veía buenas opciones. Lo revisé varias veces en el pasado; si se me pasó algo, agradecería que me lo dijeran.
    https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...
    La mayoría espera que funcione al menos como Google Docs o Notion, y desde el punto de vista del desarrollador se desea que se guarde en privado en un formato parecido a Postgres JSONB, sin tener que profundizar demasiado en los detalles de implementación.

    • En teoría, bastaría con distribuir parches serializados, pero en un backend real quizá también haga falta conocer el estado actual del documento, la identidad del usuario y cierto nivel de control de acceso.
      Varias veces quise usar Y.js en un backend en Go, pero como era difícil encontrar una implementación de referencia sencilla, terminé rindiéndome cada vez por limitaciones de tiempo.
      Incluso revisándolo de nuevo desde hace años, fuera de Node.js sigue pareciendo difícil.

  • Hace tiempo usé Yjs en un pequeño proyecto paralelo. Del lado del cliente fue bastante fácil de aprender y usar.
    Del lado del servidor quería desplegarlo como un solo binario, pero había poquísimos ejemplos en lenguajes que no fueran Node, por ejemplo con Yrs, el port a Rust.
    Al final modifiqué un poco https://github.com/yjs/y-websocket y le agregué persistencia basada en LevelDB, pero para mi caso no fue lo ideal.
    Me pregunto si hay buenos materiales para implementar el lado del servidor, incluida la persistencia, en un lenguaje como Rust.
    Por lo que recuerdo, los materiales existentes del cliente estaban muy inclinados hacia integraciones con editores de texto, así que este tutorial es realmente útil. Como no usé una integración con editor de texto, tuve que ir tanteando por mi cuenta.

    • Y-Sweet[1] podría ser lo que buscas. Es el servidor open source en Rust que impulsa el banner de Learn Yjs.
      Usa S3 o el sistema de archivos local como almacenamiento, y compila a un binario de unos pocos MB enlazado con musl.
      https://github.com/jamsocket/y-sweet

  • Dice que es una técnica de indexación fraccionaria, “donde los índices no son enteros sino fracciones”, y me pregunto cuántas veces debería poder usarse antes de detenerse.

    • Lo probé directamente y fueron 1075 veces; no es un valor enorme, así que parece que podría ser un problema importante para esta biblioteca.
      El código de prueba es el siguiente:
      let left = 0, right = 1
      let rightPrevious = 2
      let counter = 0;
      while (right > left && right < rightPrevious) {
      rightPrevious = right;
      right /= 2;
      counter++
      }
      console.log(counter)
      Miré el repositorio muy por encima, pero no encontré dónde se maneja este problema, y no tuve tiempo de investigarlo a fondo. Si es un issue real, quizá pueda ayudar a resolverlo.

  • Ahora estoy usando Yjs mientras hago una app que necesita funcionar offline.
    En realidad no es una app colaborativa en tiempo real, pero si piensas en el servidor como un colaborador y en la app como otro, es fácil imaginar el caso de uso.

  • El punto que nunca pude superar con Yjs es que, si generalizas el ejemplo del tutorial de mover elementos en una app de tareas, se vuelve complejo demasiado rápido.
    Cuando hay varios objetos relacionados entre sí, uno quiere ponerlos en el mismo Document, y mantener esas relaciones sincronizadas tiene muchas trampas como la indexación fraccionaria del tutorial.
    Luego, cuando se acumulan elementos a escala de base de datos, el modelo de juguete de meter todo en un solo documento implica que a cualquiera que quiera leer cualquier elemento hay que enviarle toda la DB y su historial.
    Al final hay que separar los elementos en objetos distintos y persistirlos uno mismo, pero no hay documentación aparte de este tutorial [0] y, con spoiler incluido, es una página vacía que lleva años diciendo “Work in Progress - come back later”.
    Así que, aunque quieras crear y administrar un Provider, la situación de la documentación es la misma [1].
    Uno descubre Subdocuments y se entusiasma pensando que quizá exista una solución para este problema común [2], pero algunos Providers no pueden manejar relaciones entre subdocumentos, y otros ni siquiera soportan subdocumentos. Al final hay que crear un Provider propio, y se vuelve al problema de que no hay documentación.
    Si intentas leer el código, terminas entendiendo que el núcleo de Yjs es, en definitiva, el protocolo. Pero ese protocolo, que es la esencia de Yjs, tampoco está completamente documentado y está disperso en varias partes de un código bastante peculiar. A menos que cuentes como documentación un paper de hace 10 años sobre cómo funcionaba el antecesor de Yjs.
    No quería escribir esto como una queja, pero durante años pasé demasiado tiempo intentando hacerlo funcionar, y la brecha entre las demos de juguete tipo “¡funciona como por arte de magia!” y algo real es enorme. La documentación de esa parte ha estado vacía durante 10 años, salvo por “Work in Progress”.
    Espero que las empresas que intentan monetizar Yjs, como la del autor de este artículo, ayuden a cerrar esa brecha.
    [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] Mientras escribía esto esperaba que la situación hubiera cambiado, pero toda la documentación parece seguir en proceso, igual que hace 5 años, y lo mismo con el soporte de subdocumentos.

  • En la demo interactiva, me desconcertó que el deslizador de latencia se comporte como un búfer de debounce, no como latencia de red. No entiendo por qué lo hicieron así.

    • Elegimos el modelo de latencia más simple que bastaba para mostrar los problemas que aparecen cuando el estado cambia en varias ubicaciones.
      La ventaja de este enfoque es que se puede implementar sin ocultarle ningún estado al lector. El gráfico circular expone tal cual el único estado interno que existe.
      El objetivo no es una simulación de red exacta, sino construir intuición.

  • La demo interactiva es preciosa. Me da curiosidad qué librerías usaron para hacerla.

    • Todo el sitio está hecho con Astro, y las demos son “islas interactivas” hechas con React.
      Las demos de hecho ejecutan Yjs por dentro. Cada “cliente” tiene su propio documento, y cuando el usuario hace clic se simula el retraso con setTimeout y luego se fusionan manualmente los documentos entre sí. También hay un tercer documento para la línea de tiempo del centro.
      Además de eso, usamos dnd kit [1] para drag and drop en la demo de tareas, Motion [2] para animaciones y CodeMirror [3] para el editor de texto.
      [1] https://dndkit.com
      [2] https://motion.dev
      [3] https://codemirror.net

  • El juego de la imagen del banner es tonto, pero divertido.

  • Por fin hice un trébol de cuatro hojas, pero después de unos 2 minutos alguien lo arruinó.
    Edición: esperen, ¿a dónde se fue todo el mundo? Creo que lo rompimos o me bloquearon. Aun así, aplausos para quien lo hizo. Es algo genial.

    • Seguro que no te bloquearon. Parece que la gente disminuyó por un momento, y ahora se ven bastantes cursores.
      Por cierto, hay dos emojis secretos más.