Cómo se compara de verdad
Las comparativas de frameworks de escritorio están casi todas mal hechas. Los cuatro trucos que las inflan, qué medir en su lugar, y cómo montar una prueba de cuatro horas que decida de verdad.
Los cuatro trucos
Truco 1 · Se compara el «hola mundo». La cifra del instalador se saca casi siempre de la plantilla vacía. Ahí Tauri gana por goleada, porque lo único que pesa es el binario. En cuanto la aplicación real entra —el frontend compilado, los recursos, las fuentes, las imágenes, los sidecars, las dependencias de Rust que arrastran su propio peso— la diferencia sigue siendo grande pero deja de ser la de los titulares. La forma honesta de decirlo es que la diferencia es de orden de magnitud, no de un factor concreto, y que el factor depende de lo que tú añadas.
Truco 2 · Se mide la memoria mal, y en el sistema equivocado. Esto merece su propia sección, abajo.
Truco 3 · Se mide en la máquina del que escribe. Un arranque en frío medido tres veces seguidas en un portátil rápido con todo en caché no es un arranque en frío: es un arranque en caliente. El primero, en una máquina que acaba de encender, con el antivirus mirando y el disco frío, puede ser cinco veces más lento. Y en Windows con protección en tiempo real activada, la primera ejecución de un binario recién descargado y firmado tiene un coste que ninguna comparativa incluye.
Truco 4 · No se mide el coste de construirlo. Ninguna tabla incluye las semanas que cuesta aprender Rust, las horas de la primera notarización fallida, ni el bug de WebKitGTK que se llevó dos días. Ese coste es real, se paga en la misma moneda que el resto —tiempo— y suele ser mayor que todo lo que la tabla ahorra.
La memoria, que es donde más se miente
Comparar memoria entre un motor empaquetado y una webview del sistema es difícil de verdad, y por tres razones que se ignoran casi siempre.
No hay un número, hay tres. Lo que muestra el monitor del sistema es memoria residente, que incluye páginas compartidas con otros procesos. Lo que consume tu aplicación de verdad es más parecido a la memoria privada. Y lo que le cuesta al sistema es otra cosa más, porque las páginas compartidas se cuentan una vez.
La webview del sistema ya estaba ahí. En macOS, parte de WKWebView es un servicio del sistema compartido entre procesos. Si el usuario ya tenía una aplicación con webview abierta, tu segunda aplicación no paga el coste completo. Contar esa memoria como tuya es tan discutible como no contarla.
Cada sistema cuenta distinto. El administrador de tareas de Windows, el monitor de actividad de macOS y ps en Linux no miden lo mismo aunque lo llamen parecido. Comparar la cifra que da uno con la que da otro no significa nada.
Lo que sí se puede afirmar sin trampa es esto: una aplicación con motor empaquetado paga un suelo de memoria por proceso que la del motor del sistema no paga, y ese suelo se multiplica por cada aplicación abierta. Con diez aplicaciones abiertas, la diferencia deja de ser una cifra de comparativa y es una cifra que el usuario nota. Con una sola aplicación abierta en una máquina con memoria de sobra, no la nota nadie.
Las tres cifras que sí deciden
Olvida las genéricas. Estas tres dependen de tu proyecto y ninguna comparativa ajena te las puede dar:
La tercera es la importante y la que nadie hace. Es también la que puede matar el proyecto: si tu vista principal va bien en dos motores y mal en el tercero, mejor saberlo la primera semana que la última.
La prueba de cuatro horas
Un procedimiento que cabe en una tarde y decide mejor que un mes de lectura:
- Elige la pantalla más difícil de tu producto. No la portada: la que tiene la tabla grande, el editor, el gráfico que se actualiza. Si no existe todavía, dibújala con datos falsos.
- Constrúyela como una web estática, sin backend. Una hora, dos si eres meticuloso. Este artefacto es el que vas a medir en todo lo demás, sin tocarlo.
- Empaquétala en los dos candidatos. Con Tauri es
create-tauri-appy apuntar la configuración a tu directorio de salida —el nivel 5 lo hace paso a paso—. Con Electron es unmain.jsde veinte líneas. - Mide las tres cifras en las tres plataformas. Si no tienes las tres máquinas, una máquina virtual sirve para descubrir los problemas gordos, que es de lo que se trata.
- Anota lo que te costó cada paso. Ese registro es la cuarta cifra, la que no sale en las tablas, y suele ser la que decide.
Al final tendrás cuatro números tuyos en lugar de veinte ajenos. Y si en el paso 4 la tercera plataforma se comporta raro, acabas de ahorrarte la fase XII entera.