Su lugar: lidera casi todo y es la más joven de las tres

Llega el momento de situar a Loro entre las tres bibliotecas del bloque, y el ejercicio es incómodo porque los dos ejes que importan apuntan en direcciones opuestas. En el eje técnico es la más ambiciosa: tiene primitivas que las otras dos no tienen, encabeza la medición sobre una traza de edición real en todas las categorías salvo una, y su única derrota es precisamente la que se deriva de su apuesta de origen. En el eje de la adopción es la más pequeña y la más joven, con la menor cantidad de descargas semanales de las tres y un ecosistema de integraciones que todavía se está formando. Ninguno de los dos ejes puede ignorarse al decidir, y cualquier recomendación que solo mire uno es una recomendación mal hecha. Esta lección junta las dos lecturas y termina con un criterio de elección que se pueda defender delante de un equipo.

Dónde lidera y dónde no

La medición de referencia reproduce una traza real de edición registrada carácter a carácter sobre un documento grande, con unas doscientas sesenta mil operaciones entre inserciones y borrados. No es un microbanco sintético: es el rastro de alguien escribiendo de verdad, y por eso es la única de las mediciones publicadas que representa algo parecido a un uso real.

Que sea una traza de un solo autor tiene además una implicación que rara vez se comenta. Al no haber concurrencia, mide el camino barato de todos los algoritmos y ninguno paga el coste de fusionar ramas divergentes. Eso la hace representativa del uso mayoritario y a la vez ciega al escenario que motiva usar un CRDT, de modo que hay que leerla como lo que es: una prueba de que no hay patologías en el caso común, no una prueba sobre el caso difícil.

Sobre esa traza Loro encabeza todas las categorías —tiempo de aplicación de las operaciones, tamaño de la codificación, memoria, tiempo de análisis del documento— con una sola excepción: el tiempo de carga inicial del módulo de WebAssembly. Y esa excepción no es una casualidad ni un descuido pendiente de corregir. Es la consecuencia directa y previsible de la decisión de la primera lección: el núcleo está escrito en Rust y llega al navegador como un artefacto binario que hay que descargar, compilar e instanciar antes de que exista una sola función llamable.

Que la única derrota sea exactamente esa es lo más informativo del cuadro, porque significa que la biblioteca no tiene un punto débil disperso sino un peaje concentrado y perfectamente identificado. Un perfil de rendimiento con una debilidad localizada es mucho más manejable que uno con varias medianías, porque admite una contramedida concreta: en este caso, mover el arranque fuera del camino crítico. Un peaje repartido por todas las operaciones no admitiría ninguna.

La forma de la comparacion sobre la traza real

  aplicar las operaciones ....... lidera
  tamano del documento .......... lidera
  memoria en reposo ............. lidera
  analizar el documento ......... lidera
  arranque del modulo ........... no lidera, y por diseno

  el unico punto perdido es el coste fijo,
  que es tambien el unico que se puede reprogramar en el tiempo

La madurez, que es una variable independiente

Aquí el retrato cambia de signo. Loro alcanzó su versión 1.0 en 2024, lo que la convierte en la más joven de las tres por un margen considerable, y su adopción medida en descargas semanales ronda las doce mil: la menor de las tres, y por bastante.

Ese hito de la versión 1.0 tiene además un significado técnico concreto que la documentación explica al justificar su formato de codificación: para garantizar compatibilidad hacia atrás y hacia adelante a partir de esa versión, adoptaron un método de codificación más extensible aunque fuera más lento que el anterior. Es la clase de sacrificio que solo se hace cuando se asume que habrá documentos guardados que deberán abrirse dentro de años, y merece ser leída como una señal de intenciones más fiable que cualquier declaración de estabilidad.

Las dos cifras están relacionadas y conviene no contarlas dos veces como si fueran dos problemas independientes: una biblioteca que estabilizó su formato de datos hace dos años tiene por fuerza menos rodaje que una que lo hizo hace ocho, y la adopción tarda en llegar incluso cuando la calidad ya está. Lo relevante no es cuál de las dos cifras es la causa, sino que ambas describen el mismo hecho desde ángulos distintos.

Ese número no mide calidad. Mide otra cosa que también importa y que conviene nombrar con precisión, porque es lo que un equipo va a encontrarse en el día a día: cuántas preguntas ya están respondidas en algún sitio, cuántos casos límite ya los ha pisado otro antes que tú, cuántas integraciones con editores y marcos existen mantenidas por terceros, cuántos proveedores de sincronización hay para elegir, y cuánta gente hay disponible que ya sepa usarla.

flowchart TB
E[eleccion de biblioteca] --> T[eje tecnico]
E --> M[eje de madurez]
T --> T1[primitivas disponibles]
T --> T2[rendimiento medido]
M --> M1[adopcion y respuestas existentes]
M --> M2[integraciones y proveedores]
T1 --> D[decision informada]
T2 --> D
M1 --> D
M2 --> D
style T fill:#a6e3a1,color:#11111b
style M fill:#f9e2af,color:#11111b

Dos preguntas que la adopcion responde y la calidad no

  cuando te encuentres un caso limite raro
    con adopcion alta ... alguien lo describio y hay un hilo con la respuesta
    con adopcion baja ... lo describes tu, y quiza te contestan

  cuando necesites una pieza de alrededor
    con adopcion alta ... hay varias, mantenidas por terceros
    con adopcion baja ... hay una oficial, o la escribes

  ninguna de las dos preguntas mide si la biblioteca es buena

// La prueba honesta no es un banco de pruebas: es tu peor caso
// escrito dos veces detras de la misma interfaz propia
export function crearDocumentoDeProyecto() {
  const doc = new LoroDoc();
  doc.configTextStyle({ bold: { expand: "after" } });
  return {
    titulo: doc.getText("titulo"),
    arbol: doc.getTree("tareas"),
    exportar: () => doc.export({ mode: "snapshot" }),
  };
}

Conviene matizar el retrato en un punto, porque el ecosistema propio de Loro no está vacío. Existen enlaces oficiales para los dos editores que importan en la práctica —uno para el marco de edición enriquecida más extendido, que además funciona con el editor construido encima de él, y otro para el editor de código— y ambos cubren sincronización de estado, presencia de cursores y deshacer colaborativo. Lo que está menos poblado es lo de alrededor: proveedores de red de terceros, integraciones con marcos de interfaz, herramientas de depuración y, sobre todo, historias de producción publicadas con años de rodaje.

Lo que solo tiene Loro

Si se mira la tabla comparativa que la propia documentación publica frente a las otras bibliotecas, hay dos filas donde Loro aparece sola y son justamente las de este nivel. Vale la pena leer esa tabla con la desconfianza que merece cualquier comparativa escrita por una de las partes, pero también reconocer que sus filas son verificables una a una: o el contenedor existe en la biblioteca o no existe.

Conviene añadir un matiz sobre la fila del texto enriquecido, porque es la que más se malinterpreta en las comparativas. Que una biblioteca no modele el formato como estructura convergente no significa que no se pueda escribir un editor con formato encima de ella: significa que las fusiones de formato concurrente se resolverán con reglas improvisadas escritas por ti o por el enlace del editor, y que los casos difíciles de la lección anterior quedarán a tu cargo. La diferencia no aparece en la demostración; aparece a los seis meses, cuando dos personas formatean el mismo párrafo desde dos dispositivos.

Hay también una fila donde Loro aparece como la que no tiene: la tolerancia a fallos bizantinos, que sí ofrece una de las otras dos. Traducido a decisiones, significa que Loro asume participantes que pueden desconectarse pero no participantes que mientan sobre su propia historia; si tu modelo de amenaza incluye réplicas maliciosas, esa fila decide por ti antes que cualquier medición de rendimiento.

Merece la pena señalar una ironía del cuadro que dice mucho sobre cómo avanza este campo. Las dos filas donde Loro está sola corresponden a algoritmos publicados por investigadores vinculados a las bibliotecas rivales: el movimiento en árboles replicados y el movimiento de elementos en listas salieron de ese entorno, y sin embargo quien los lleva a producción como contenedor nativo es la biblioteca más joven. Publicar un algoritmo y encajarlo en una biblioteca existente son dos trabajos distintos, y el segundo es más fácil cuando aún no arrastras un formato de datos con años de compatibilidad que preservar.

Cuándo elegirlo hoy

La propia documentación abre con una sección que casi ninguna biblioteca se atreve a escribir: cuándo no usarla. Enumera cuatro situaciones —cuando se necesita consistencia fuerte, cuando los datos no tienen forma de documento estructurado, cuando basta con una sincronización cliente servidor sencilla, y cuando la aplicación es sensible al tamaño del paquete— y la última es, otra vez, la contrapartida de la apuesta.

Las tres primeras conviene leerlas despacio porque descartan más proyectos de los que parece. La consistencia fuerte excluye todo lo que tenga invariantes globales que no puedan violarse ni un instante: saldos, inventarios, reservas de asientos. Los datos sin forma de documento estructurado excluyen el vídeo, el audio y los ficheros binarios grandes, que no ganan nada con fusionarse. Y la tercera es la más olvidada: si tu aplicación siempre tiene servidor, siempre tiene red y nunca edita en paralelo de verdad, un canal de mensajes y una tabla te dan lo mismo por una fracción del coste conceptual.