El otro camino: los que no usan un navegador

Dos subcampos que se confunden

Se meten en el mismo saco y se comportan de forma opuesta.

Los que pintan su propio lienzo. El framework recibe una superficie acelerada por GPU y dibuja cada píxel: los bordes, el texto, el cursor, la barra de desplazamiento. Flutter es el ejemplo grande; Slint, Iced y Compose Multiplatform juegan aquí también. La interfaz se ve exactamente igual en todos los sistemas, porque no toma nada prestado.

Los que envuelven controles nativos. El framework no dibuja: pide al sistema que dibuje sus propios botones, campos y listas, y ofrece una API común encima. Qt en su modo de widgets, Avalonia en parte, MAUI. La interfaz es del sistema: sus menús contextuales, su selección de texto, su comportamiento con el lector de pantalla.

Qué gana quien renuncia a HTML

Vale la pena entenderlo bien, porque el argumento habitual —«va más rápido»— es demasiado vago para decidir.

Un navegador es un motor de documentos con un modelo de disposición pensado para texto que fluye: la cascada, el modelo de caja, el recálculo de estilo, un árbol de nodos con reglas heredadas. Toda esa maquinaria es lo que permite escribir una interfaz en un rato. También es lo que hace que, cuando el árbol tiene cien mil nodos y cambian a la vez, el trabajo por fotograma sea enorme.

Un motor de lienzo no tiene nada de eso. Sabe dónde va cada rectángulo porque tú se lo dijiste, y dibujar un fotograma es enviar geometría a la GPU. Por eso las interfaces con muchísimos elementos que cambian a la vez —una línea de tiempo de vídeo, un editor de nodos, una tabla de datos gigante, una vista de un mapa— van mejor en este campo, y no por poco.

El precio es todo lo que el navegador te daba gratis: el cursor de texto que se comporta como el del sistema, la selección con el ratón, el menú contextual, el lector de pantalla, el zoom del sistema, la entrada de texto de idiomas complejos. Los frameworks maduros de este campo lo han reconstruido; los jóvenes están en ello.

Las tres señales de que estás en el campo equivocado

Si al leer esto reconoces tu proyecto en dos de las tres, cierra el track y ábrete otro:

1. La interfaz es el producto y es exigente. Un editor de vídeo, una herramienta de diseño, un DAW, un editor de nodos, un visor de datos masivos. No una aplicación con una tabla grande: una aplicación cuyo valor es pintar cosas complejas a sesenta fotogramas por segundo.
2. Tiene que verse y comportarse como una aplicación del sistema, y eso no es negociable. Software corporativo que convive con otras herramientas nativas, o cualquier cosa donde un usuario avanzado va a notar que el menú contextual no es el suyo.
3. No hay ningún futuro en la web. Si tu producto nunca va a tener versión web y tu equipo no viene del frontend, la mayor ventaja de Tauri —reutilizar interfaz y personas— no aplica, y estás pagando el defecto de los tres motores sin cobrar la ventaja.

Si en cambio tu interfaz es fundamentalmente formularios, listas, texto, paneles y navegación —que es la inmensa mayoría del software— el navegador es una herramienta excelente para eso, y la ventaja de reutilizar la web pesa más que todo lo demás.