Los tres campos
Todo framework de escritorio responde a una sola pregunta —quién pinta los píxeles— y las respuestas posibles son tres. Entender los campos ordena un catálogo de veinte nombres en un minuto.
La pregunta que los separa
Esa es toda la taxonomía. Ahora se puede predecir el comportamiento de cada campo sin haber escrito una línea.
Campo 1 · La webview del sistema
La idea. No enviar un motor: usar el que la máquina ya tiene. Tu interfaz es HTML, CSS y JavaScript, y la pinta WKWebView, WebView2 o WebKitGTK según dónde se ejecute.
Lo que se deduce sin probarlo:
- El instalador es pequeño, porque el motor no viaja. Megabytes, no cientos.
- La interfaz se ve distinta en cada sistema, porque son tres motores con tres calendarios. Este es el defecto estructural del campo, y ningún framework de aquí lo ha resuelto.
- El equipo escribe frontend web, así que la curva de entrada es corta y la misma interfaz puede servirse también como web.
- La lógica pesada tiene que salir del JavaScript, porque la webview es un intérprete de propósito general con un solo hilo cómodo. Ahí es donde cada framework de este campo elige un lenguaje distinto.
Quiénes son: Tauri (Rust), Wails (Go), Neutralino (un binario ligero con extensiones).
Campo 2 · El motor empaquetado
La idea. Enviar el navegador dentro del instalador. Tu aplicación no depende de lo que haya en la máquina porque lleva su propio Chromium.
Lo que se deduce:
- El instalador es grande y la memoria en reposo, alta: es un navegador entero, uno por aplicación abierta.
- La interfaz se ve idéntica en todas partes, porque es siempre el mismo motor. Esta es la ventaja del campo, y es una ventaja de verdad.
- Puedes usar cualquier característica del navegador sin comprobar si está disponible, porque tú eliges la versión.
- Actualizar el motor es tu trabajo. Un fallo de seguridad de Chromium es tuyo hasta que publiques una versión nueva.
Quiénes son: Electron es el campo entero, en la práctica. Hay variantes que empaquetan CEF directamente, y son la misma idea con menos comodidades.
Campo 3 · El motor de render propio
La idea. No usar un navegador en absoluto. O pintas cada píxel tú mismo sobre un lienzo acelerado por GPU, o llamas directamente a los controles nativos del sistema.
Son dos subcampos con consecuencias muy distintas, y conviene no mezclarlos:
- Pintan su propio lienzo (Flutter, Slint, Iced, Compose Multiplatform): la interfaz se ve exactamente igual en todas partes porque no toma nada prestado del sistema. A cambio, no es del sistema: el menú contextual, la selección de texto, el lector de pantalla y los gestos hay que reimplementarlos o vivir sin ellos.
- Envuelven controles nativos (Qt en parte, Avalonia en parte, MAUI): la interfaz usa los widgets reales de cada plataforma, así que se ve y se comporta como el sistema. A cambio, las diferencias entre sistemas se te aparecen a ti, y hay que programar contra el mínimo común denominador.
Lo que se deduce del campo entero: el lenguaje deja de ser negociable —Dart, C++, C#, Rust, Kotlin— y con él todo el ecosistema. No hay reutilización con la web. Y el rendimiento de la interfaz puede ser muy superior, porque no hay un motor de documentos en medio.
Dónde está Tauri, y con quién comparte defectos
Tauri hereda las tres ventajas de su campo —instalador diminuto, motor que actualiza el sistema, accesibilidad del navegador— y también su defecto grande: tres motores que no controlas. Lo que Tauri añade sobre sus vecinos de campo es el lenguaje del core y el modelo de permisos, y eso es el tema del nivel 2.3 y del 3.