Lo que una pestaña no puede hacer

El sandbox de origen, que lo explica todo

Un navegador ejecuta código de desconocidos sin preguntar. Abres un enlace y, medio segundo después, hay JavaScript de alguien a quien no conoces corriendo en tu máquina. Que eso sea seguro es un logro de ingeniería enorme, y el precio es una regla simple: el código de una página solo puede tocar lo que pertenece a su origen, y para todo lo demás necesita que el usuario lo conceda, gesto a gesto, cada vez.

De esa regla salen en línea recta casi todas las diferencias. No es que el navegador «no tenga» acceso al disco: es que tener acceso al disco sin más sería una vulnerabilidad, porque el que pide el acceso no eres tú, es la página que acabas de abrir.

Una aplicación instalada invierte la premisa. Alguien decidió instalarla —descargó un fichero, aceptó un diálogo, quizá introdujo su contraseña— y con ese gesto le concedió, de una vez y para siempre, los permisos de su cuenta de usuario. La instalación es el consentimiento. Todo lo que sigue se deduce de ahí.

Las capacidades que el navegador niega

Las tres trampas de «ya existe una API web para eso»

Cada pocos meses aparece una propuesta que promete cerrar el hueco. Merece la pena saber por qué casi nunca lo cierra del todo.

La API existe pero pide permiso cada vez. La File System Access API es el ejemplo canónico. Puedes abrir un fichero y guardar el handle en IndexedDB para reutilizarlo, sí. Pero el permiso caduca, el usuario tiene que reconfirmarlo, y no hay forma de recuperar el acceso a un directorio sin que alguien vuelva a señalarlo. Para un editor de texto que abre un fichero puntual es aceptable; para una herramienta que sincroniza una carpeta de trabajo, no.

La API existe pero solo en un navegador. Buena parte de las capacidades más ambiciosas —dispositivos USB, serie, HID, Bluetooth— viven solo en los navegadores basados en Chromium. Si tu aplicación tiene que funcionar en el Safari de alguien, no existen. Y si el usuario usa Firefox, tampoco.

La API existe pero el modelo no encaja. Un Service Worker parece un proceso de fondo y no lo es: el navegador lo despierta cuando le conviene, lo mata cuando quiere y no le da interfaz. Sirve para responder a una petición de red o a una notificación push; no sirve para indexar una biblioteca de veinte mil ficheros mientras el usuario hace otra cosa.

Lo que no está en la lista, y sorprende

Tres cosas que la gente da por sentadas y no son diferencias reales:

• El rendimiento. Una webview es el mismo motor que el navegador. Si tu interfaz va lenta en una pestaña, irá igual de lenta dentro de una app de escritorio, porque es literalmente el mismo código pintando. Lo que gana Tauri es el trabajo pesado, que se puede llevar a Rust; la interfaz no cambia sola de velocidad al empaquetarla.
• El aspecto nativo. Una app hecha con webview se ve como una web dentro de una ventana, a menos que trabajes deliberadamente el chrome, los menús y los gestos del sistema. La ventana la da el framework; la sensación, no.
• Funcionar sin conexión. Una aplicación web bien hecha funciona sin red perfectamente: es de lo que trata entero el track de Local-First. Si tu única razón para bajar al escritorio es el modo sin conexión, probablemente no necesitas bajar.