El dato que es tuyo
El argumento que no es técnico y decide más arquitecturas que ninguno: dónde acaban tus datos, si podrías encontrarlos sin la aplicación, y qué pasa con ellos el día que la empresa cierra o cambia de precio.
La prueba
Coge una aplicación que uses para algo que te importe —notas, contabilidad, fotos, código, un proyecto— y contesta cuatro preguntas en orden. Cada una es más dura que la anterior.
Lo interesante de la prueba es que la respuesta no depende de si la aplicación es web o de escritorio. Hay aplicaciones instaladas que guardan todo en un formato binario cerrado y aplicaciones web que exportan un directorio de ficheros de texto limpios. Lo que decide es una elección de diseño, no una plataforma. Bajar al escritorio te da la posibilidad de aprobar la prueba; no te la aprueba.
Tener, leer, entender
Las tres son distintas y se confunden todo el rato.
Tener el fichero es lo mínimo, y es lo que da el escritorio de serie. Un directorio en tu disco con algo dentro.
Poder leerlo significa que existe una herramienta que abre ese formato y no es la que lo escribió. Un .sqlite cumple: hay clientes por todas partes. Un ZIP con XML dentro cumple a duras penas. Un volcado de estructuras de Rust serializadas en binario no cumple, aunque el fichero esté en tu disco y puedas copiarlo.
Poder entenderlo es que, una vez abierto, los datos tengan sentido. Una base SQLite con tablas llamadas t1, t2 y una columna blob con JSON comprimido dentro se lee y no se entiende. Ese caso es más común de lo que parece, y suele ser accidental: nadie diseñó el esquema pensando en que alguien lo leyera.
Qué hace bien el escritorio aquí
Tres cosas concretas, y ninguna es automática:
El fichero tiene una ruta que puedes escribir en un papel. Eso permite copias de seguridad con las herramientas del sistema, sincronización con lo que el usuario ya use, control de versiones si es texto, y —lo más subestimado— que otra herramienta pueda leerlo sin pedirle permiso a nadie.
No hay una cuenta entre tú y tus datos. Una aplicación de escritorio puede funcionar sin autenticar a nadie. Eso elimina de golpe una clase entera de problemas: la sesión que caduca, el servidor caído, el cambio de términos, la migración de proveedor de identidad.
SQLite es una opción de verdad. No como sustituto de un servidor, sino como formato de fichero: transaccional, consultable, con un ecosistema de herramientas de treinta años y una especificación de formato que la propia gente de SQLite se comprometió a mantener legible durante décadas. La fase VII lo trata en serio, y el concepto SQLite recoge dónde más aparece en el centro de estudios.
Dónde acaba este argumento y empieza otro track
Aquí conviene poner un límite honesto. La propiedad del dato, la longevidad y el control del usuario son el corazón de local-first, que en este centro de estudios es un track de cincuenta y nueve niveles con su propia teoría —convergencia, CRDT, relojes lógicos, motores de sincronización—. Este nivel solo toma prestada la parte que decide si bajas al escritorio o no.
La relación entre los dos es simple y merece decirse ya: Tauri es una concha, local-first es una arquitectura de datos. Puedes hacer una app de Tauri que sea un cliente tonto de un servidor —y muchas lo son— y puedes hacer una aplicación web rigurosamente local-first sin instalar nada. Se juntan bien, y el nivel 79 cierra el track precisamente con esa unión, pero no son lo mismo ni una implica la otra.