¿Cómo es Linear tan rápido? Un desglose técnico

UI optimista y “Sync Engines”

• Muchos comentarios dicen que la idea central es bien conocida: actualizaciones optimistas en el cliente con sincronización en segundo plano, similar a Meteor, Google Docs o la predicción del lado del cliente en juegos multijugador.
• Se ve un “sync engine” como una forma formalizada de gestionar un almacén normalizado en el cliente, mutaciones optimistas y reconciliación, simplificando el código de la UI una vez que está en su sitio.
• Algunos sostienen que el artículo presenta este patrón como algo novedoso o exclusivamente de “Linear” de forma exagerada.

Corrección, consistencia y modos de fallo

• Existe una fuerte preocupación de que las UI optimistas puedan “mentir” a los usuarios: la interfaz muestra éxito antes de que el servidor confirme el commit.
• Se plantean escenarios como fallo de red, cierre de la pestaña/navegador antes de la sincronización, largos periodos sin conexión, deriva del esquema, ediciones en conflicto, eliminaciones frente a ediciones, y conflictos de reordenación.
• Algunos dicen que las tasas de conflicto son bajas y que los buenos sync engines gestionan rollback, resolución de conflictos e ինտentos de reintento offline; otros dicen que esto es muy difícil en la práctica y propenso a pérdida de datos y confusión del usuario.
• Se debate la persistencia del almacenamiento del navegador: puede ser expulsado, y depender de él como fuente de verdad se considera arriesgado.

Latencia vs arquitectura (local-first vs CRUD rápido)

• Un bando argumenta que, con backends bien situados, stacks eficientes y buen SSR, las operaciones CRUD típicas pueden ser de ~30–100 ms, haciendo innecesaria una sincronización local-first compleja.
• Otro bando responde que la latencia global, la física y las colas de latencia hacen que muchos usuarios vean rondas de ~300 ms o más, así que local-first es la única forma de sentirse “instantáneo”.
• Se discuten el sharding/regiones locales por tenant frente al estado compartido global, y que “acercar la base de datos” en esencia recrea de todos modos un problema de sincronización distribuida.

Detalles de implementación y herramientas

• IndexedDB se usa comúnmente, pero se considera incómodo; se mencionan wrappers como idb, localforage, TinyBase y soluciones SQLite-in-WASM.
• Algunos destacan productos de sincronización dedicados (Zero, Replicache, PowerSync, etc.) como formas de lograr un comportamiento similar al de Linear sin construir un motor propio, mientras que otros no gustan de los DSLs/el vendor lock-in y prefieren una replicación personalizada basada en SQL.

UX y rendimiento percibido de Linear

• Las opiniones sobre la UX y la velocidad de Linear están fuertemente divididas.
• Los fans lo califican como una de las mejores y más rápidas aplicaciones web; una mejora enorme frente a Jira y herramientas similares.
• Los críticos reportan uso alto de CPU/memoria, búsquedas y cargas iniciales lentas, una interfaz confusa o “oculta”, comportamiento inestable de las pestañas, estados de sincronización “atascados” y una creciente acumulación de funcionalidades.
• Varios señalan que el rendimiento en las interacciones principales puede ser bueno, pero la carga inicial o la latencia en la búsqueda socavan la narrativa de que “es tan rápido”.

Cuándo usar sync engines

• Muchos ven la sincronización local-first como potente pero no trivial, y la reservan para apps donde una UX instantánea y colaborativa realmente importa.
• Otros argumentan que la mayoría de las apps están mejor con CRUD más simple y fuertemente consistente, junto con optimizaciones específicas en backend y frontend.