No empaquetar un navegador
La primera mitad de la tesis: usar el motor que la máquina ya tiene. Qué se ahorra de verdad, qué se gana en seguridad sin escribir una línea, y cuál es exactamente la deuda que se contrae a cambio.
Qué desaparece
Un motor de navegador moderno es de las piezas de software más grandes que existen: el analizador de HTML, el motor de CSS con su cascada, un intérprete de JavaScript con compilación en tiempo de ejecución, una pila de red completa con TLS, un decodificador de imágenes, uno de vídeo, un compositor, un sistema de sandbox por procesos. Empaquetarlo significa que cada una de esas piezas viaja en tu instalador y se copia en el disco de cada usuario.
Cuando no viaja, desaparecen tres cosas a la vez, y solo la primera es de tamaño:
El peso, que es el titular. Del orden de cientos de megabytes menos por instalador. Y no solo en disco: también en descarga, en ancho de banda de tu servidor de actualizaciones, y en tiempo de instalación.
La responsabilidad de parchearlo, que es lo importante. Cuando el motor viaja contigo, cualquier vulnerabilidad suya es tuya: tienes que integrar la versión nueva, recompilar, firmar, notarizar y publicar, y esperar a que cada usuario acepte. Cuando el motor lo pone el sistema, esa vulnerabilidad la parchea el sistema operativo, en su ciclo de actualizaciones, sin que tú publiques nada. Para un equipo pequeño esto no es una comodidad: es la diferencia entre poder mantener el software y no poder.
El proceso de compilación, en parte. No hay que descargar, verificar ni empaquetar un artefacto de cientos de megabytes en cada construcción.
Lo que no se ahorra
Tres creencias frecuentes que conviene desmontar antes de que decidan algo:
No se ahorra el trabajo de hacer que la interfaz vaya rápido. El motor es el mismo que el del navegador. Una vista con diez mil nodos que se recalculan va igual de mal dentro de una app de Tauri. Lo que Tauri ofrece es un sitio adonde llevar el cálculo pesado —el core—, no un motor de render mejor.
No se ahorra memoria por arte de magia. Se ahorra el suelo de tener un motor por aplicación, que es real y se nota con varias aplicaciones abiertas. La memoria que consume tu interfaz es la misma. El nivel 58 desmonta esto en detalle porque es el mito más repetido del framework.
No se ahorra probar en varios navegadores. Al contrario: se cambia probar en tres navegadores que el usuario mantiene actualizados por probar en tres motores que nadie actualiza a propósito. Es peor, no mejor. Nivel 3.3.
La deuda, formulada bien
La forma habitual de decirla —«tu app se verá un poco distinta en cada sistema»— es demasiado suave y desvía la atención a lo estético, que casi nunca es el problema. La formulación precisa es esta:
Tu aplicación se ejecuta sobre un componente que ni tú ni el usuario habéis elegido, cuya versión no controláis, que cambia por debajo con las actualizaciones del sistema, y que en una de las tres plataformas puede ser de hace años.
De ahí salen cuatro consecuencias concretas, y ninguna es de estética:
- Una característica de CSS o de JavaScript puede no existir en una plataforma. No es un problema si compruebas la disponibilidad y degradas; es un problema si te enteras por un informe de un usuario.
- Un fallo del motor es un fallo tuyo, y no lo puedes arreglar. Solo esquivar. El nivel 3.4 tiene ejemplos reales de esto en Linux.
- Una actualización del sistema operativo puede romper tu aplicación sin que tú hayas tocado nada. Es raro y ocurre.
- La superficie de pruebas se triplica de verdad. No «conviene probar en los tres»: hace falta, y en integración continua, desde la primera semana.
Por qué la deuda compensa casi siempre
Con la tabla delante, la decisión parece reñida. En la práctica se decanta por dos razones que la tabla no muestra:
La primera es que la mayoría de las interfaces no necesitan características recientes del navegador. Formularios, listas, texto, paneles, navegación, gráficos sencillos: todo eso funciona en los tres motores desde hace años. La fila que más asusta afecta poco al software que se escribe de verdad.
La segunda es que el coste de parchear un motor empaquetado es continuo y el de probar en tres motores es en su mayor parte inicial. Una vez que la integración continua compila y prueba en las tres plataformas, el coste marginal por versión es pequeño. Mantener al día un Chromium empaquetado, en cambio, no baja nunca.