Elegir una pila de interfaz gráfica en JavaScript según lo que realmente descargan sus usuarios

Al buscar un “kit de herramientas GUI para JavaScript”, suele aparecer listas que sitúan a Electron junto a Material UI como si fueran competidores. Pero no lo son: uno proporciona una ventana instalable, mientras que el otro ofrece botones para incluir en ella; la mayoría de los productos reales necesitan uno de cada. Esta guía separa estas dos capas, analiza las principales opciones de cada una y aplica una única pregunta decisiva a ambas: ¿cuánto código termina en las máquinas de los usuarios y cuánto de ello era realmente necesario?

Dos capas que otros lenguajes combinan

En ecosistemas como Qt, GTK o WinForms, un kit de herramientas GUI hace todo a la vez: abre una ventana nativa y proporciona los widgets que se encuentran dentro de ella. JavaScript divide esa responsabilidad entre dos tipos de herramientas, y confundirlos es lo que hace que la mayoría de las comparaciones resulten complicadas.

• Cáscaras de escritorio convierten el código web en una aplicación instalable. Lo que proporcionan es el marco de la aplicación: una ventana nativa, integración en la bandeja del sistema, acceso a archivos locales y un instalador. Los widgets no forman parte de esto.
• Bibliotecas de componentes ofrecen las partes interactivas, como botones, tablas, selectores de fecha y diálogos. Se ejecutan en un navegador e independen de si dicho navegador está integrado en una aplicación de escritorio o es una pestaña normal.

Un producto de escritorio podría combinar Tauri con MUI; un producto web podría utilizar solo MUI. Elegir una cáscara y elegir una biblioteca de componentes son dos decisiones separadas.

La pregunta que realmente diferencia las opciones

En algunos ecosistemas, la licencia es el factor decisivo, ya que una obligación incorrecta puede obligar a hacer open source su producto. En el mundo de las GUI en JavaScript, casi todo está bajo licencia MIT, por lo que la licencia rara vez restringe las opciones. Lo que sí lo hace es el tamaño. En el caso de las herramientas de línea de comandos, la diferencia está entre un instalador de unos pocos megabytes y uno de varios cientos. En el caso de las bibliotecas de componentes, la diferencia radica entre entregar todo un sistema de diseño y solo los pocos componentes que realmente se utilizan. Tenga esta cuestión en mente durante toda la lectura de las siguientes secciones.

Los números de versión citados aquí reflejan la situación de npm en el momento de redactar este texto; consulte el registro antes de confiar en ellos. Para un análisis más detallado específicamente del lado de escritorio, incluidos los entornos de ejecución más recientes, consulte nuestra comparación de las opciones para escritorio de Electron, Tauri, Electrobun y Deno.

Shell de escritorio

Electron: la opción predeterminada probada que incluye su propio navegador

Electron (v44.3.0 en el momento de redactar este texto, licencia MIT) se agrega como dependencia de desarrollo:

npm install --save-dev electron

Empaqueta un navegador Chromium completo junto con un entorno de ejecución de Node.js para tu aplicación. La interfaz de usuario es una página web y el backend está basado en Node. Su mayor ventaja es su madurez: VS Code, Slack, Discord, Figma y 1Password están todos desarrollados con él, y existen herramientas bien documentadas para el empaquetado, las actualizaciones automáticas, la firma de código y la generación de informes de fallos que ya conocen muchos equipos.

La segunda ventaja es la renderización consistente. Dado que se distribuye el navegador, la aplicación tiene un aspecto idéntico en Windows, macOS y Linux, y se prueban contra una sola versión de Chromium en lugar de tres visualizadores web diferentes del sistema. Además, es completamente basado en JavaScript, por lo que cualquier desarrollador frontend puede trabajar en el proceso principal.

La desventaja es que cada aplicación incluye un navegador. Los paquetes suelen tener entre 80 y 200 MB, y como cada aplicación Electron inicia un Chromium separado, el consumo de RAM aumenta rápidamente cuando un usuario ejecuta varias de ellas. También es su responsabilidad aplicar parches a ese Chromium integrado, según su propio calendario de lanzamientos.

Tauri: la vista web del sistema más un backend en Rust

Tauri (v2.11.4 en el momento de escribir esto, con licencia dual Apache-2.0 o MIT) cuenta con su propio comando de creación:

npm create tauri-app@latest

En lugar de incluir un navegador, Tauri utiliza la vista web que ya proporciona el sistema operativo, y su backend está escrito en Rust en lugar de Node. La diferencia de tamaño es estructural y no incremental: según las cifras comúnmente reportadas, los paquetes de Tauri tienen un tamaño aproximado de 3 a 10 MB, frente a 120 a 200 MB en el caso de Electron; además, su consumo de memoria es un 50 a 75 por ciento menor y su inicio es más rápido. Dado que esta diferencia proviene de la arquitectura y no de ajustes adicionales, se mantiene constante en todas las versiones.

También difiere el modelo de seguridad. En Electron, el JavaScript del frontend puede acceder al sistema operativo a través de Node, a menos que se restrinja ese acceso. En Tauri, el frontend comienza sin acceso al sistema; las operaciones con privilegios son funciones en Rust que el frontend invoca por nombre, y Tauri v2 introdujo un sistema de capacidades que controla qué APIs puede llamar cada ventana. Tauri 2 también está dirigido a iOS y Android, algo que Electron no hace en absoluto, lo cual es importante para los equipos que desean tener un único código base tanto para escritorios como para dispositivos móviles.

Las desventajas son reales. La vista web propia de cada plataforma se renderiza ligeramente de manera diferente, por lo que ahora está probando tres motores en lugar de uno. Cualquier cosa más allá del frontend requiere algo de Rust. En Windows, Tauri depende de WebView2, que está presente en prácticamente todas las instalaciones modernas, pero ocasionalmente necesita un iniciador. Una regla sensata: si el tamaño del paquete aún no es motivo de queja por parte de los clientes, elegir Tauri únicamente para ahorrar megabytes es optimizar demasiado pronto. Úselo cuando los instaladores compactos, un bajo consumo de memoria, una aislación más estricta o una versión para móviles sean requisitos reales.

NW.js: el empaquetador de Chromium más antiguo

NW.js (v0.115.0 en el momento de escribir esto, licencia MIT) se instala como un paquete normal:

npm install nw

También incluye Chromium y, de hecho, es anterior a Electron. Su característica distintiva es que Node y el DOM comparten un mismo contexto, por lo que una página web puede llamar directamente a las API de Node, sin la separación entre procesos principal y renderizador que existe en Electron. Para algunas aplicaciones, esto simplifica su desarrollo. El sacrificio es una comunidad mucho más pequeña: menos material de aprendizaje, menos herramientas de empaquetado y menos ayuda cuando se encuentran problemas, mientras que los archivos resultantes siguen siendo tan grandes como los de Electron.

Neutralino: el wrapper más pequeño posible

Neutralino (CLI v11.7.2 en el momento de escribir esto, licencia MIT) funciona a través de una CLI instalada globalmente:

npm install -g @neutralinojs/neu

Se trata de un binario nativo ligero que rodea al webview del sistema, sin incluir ni Node ni Chromium. Los paquetes suelen tener entre 1 y 5 MB, incluso más pequeños que Tauri debido a la menor cantidad de framework involucrados. Si lo único que necesitas es envolver una interfaz web existente y agregar un ícono en la bandeja, así como funcionalidades simples de persistencia y acceso limitado a archivos, Neutralino es la opción con menos recursos para cumplir la tarea. Cuenta con el ecosistema más pequeño y el conjunto de capacidades nativas más restringido de los cuatro, por lo que debe considerarse como un framework utilitario y no como una plataforma para aplicaciones complejas.

Bibliotecas de componentes

Todo en esta categoría se ejecuta en un navegador, por lo que cada opción funciona igualmente bien tanto dentro de una shell de escritorio como en una pestaña normal. Aquí, el factor de tamaño pasa de ser el del instalador a ser la cantidad de código de biblioteca que incluye tu paquete.

MUI: cobertura máxima, estilo Material por defecto

MUI (v9.4.0 en el momento de redactar, licencia MIT) se instala junto con su motor de estilo Emotion:

npm install @mui/material @emotion/react @emotion/styled

Dentro de las bibliotecas de componentes de React, es la más grande y con mayor trayectoria, y sigue el sistema Material Design de Google. La cobertura de componentes es enorme, la documentación es excelente y su cuadrícula de datos puede manejar volúmenes significativos de información. Si necesita un componente, casi con certeza MUI lo tiene, y ya alguien ha planteado su misma pregunta al respecto.

También se trata de una biblioteca bastante grande. Una instalación nueva ocupa alrededor de 19 MB en node_modules; eso no es lo que llega a los usuarios, pero indica su envergadura. El paquete final que se envía depende de que el proceso de tree-shaking funcione correctamente, y a menos que invierta en personalización temática, todo tendrá el aspecto de Material Design, lo cual algunas equipos desean mientras que otras lo consideran restrictivo.

shadcn/ui: copia el código fuente en lugar de agregar una dependencia

shadcn/ui (CLI v4.21.0 en el momento de escribir esto, licencia MIT) no es un paquete que se importe. Su CLI inicializa un proyecto y luego copia los componentes individuales dentro de él:

npx shadcn@latest init
npx shadcn@latest add button dialog

Cada componente combina las primitivas de Radix UI con estilos de Tailwind, y después de que ejecuta la CLI, solo queda código fuente en tu repositorio. Si un botón necesita un comportamiento diferente, lo editas directamente; no existe ningún componente contenedor, ninguna API de tematización con la que lidiar ni ningún mantenedor al que convencer. Además, mantiene el paquete honesto: agrega cuatro componentes y solo esos cuatro terminan incluidos en la compilación.

El costo real de su uso es el mantenimiento. Ningún npm update mejorará tus componentes; actualizar significa copiarlos de nuevo y reconciliar los cambios a mano. Además, asume el uso de Tailwind, lo que lo hace inadecuado para proyectos que no lo utilizan. Este modelo funciona porque invierte la relación habitual entre comodidad y personalización: obtienes un punto de partida sólido y control total, pero a cambio las actualizaciones se convierten en tu problema.

Ant Design: diseñado para pantallas empresariales densas

Ant Design (v6.6.3 en el momento de escribir esto, licencia MIT) proviene de Alibaba y se instala como un único paquete:

npm install antd

Ofrece el conjunto más completo de componentes para interfaces empresariales con grandes volúmenes de datos: tablas avanzadas, formularios complejos, listas de transferencia y selecciones en forma de árbol. Para consolas de administración y herramientas internas, es probable que el widget que necesitas ya exista. También es la biblioteca más pesada de esta lista, con aproximadamente 61 MB en el disco después de la instalación, casi tres veces más que MUI; además, su fuerte identidad visual es notablemente más difícil de abandonar que la de Material.

Mantine: buenas opciones predeterminadas sin opiniones excesivas

Mantine (v9.6.1 en el momento de escribir esto, licencia MIT) separa sus componentes principales de un paquete de hooks:

npm install @mantine/core @mantine/hooks

Los equipos que consideran que MUI es demasiado prescriptivo y shadcn/ui demasiado detallista suelen llegar aquí. Cuenta con un amplio conjunto de componentes, valores por defecto razonables, tematización sencilla, un sólido soporte para TypeScript y un buen soporte para el modo oscuro sin necesidad de configuraciones adicionales. Incluso por separado, el paquete hooks, con herramientas para detectar clics fuera del elemento, almacenamiento local y consultas de medios, es útil por sí mismo. Su comunidad es más pequeña que la de MUI o Ant Design, por lo que hay menos extensiones de terceros y menos soluciones listas para usar.

Radix UI y Headless UI: comportamiento sin estilo

Radix UI (v1.1.23 en el momento de escribir) y Headless UI (v2.2.10), ambos bajo licencia MIT, se instalan por cada primitivo o como un único paquete respectivamente:

npm install @radix-ui/react-dialog
npm install @headlessui/react

Se trata de primitivas sin estilo. Ellas se encargan del comportamiento, la navegación por teclado, la gestión del foco y la accesibilidad, dejando todas las decisiones visuales en tus manos. Esa separación es valiosa porque los widgets accesibles son más complejos de lo que parecen. Un diálogo adecuado debe mantener el foco dentro de sí mientras está abierto, devolverlo al cerrarse, cerrarse con la tecla Escape y ser anunciado correctamente por las tecnologías de asistencia; un menú desplegable adecuado necesita navegación con las teclas de flecha, selección al escribir y una ubicación sensata cerca de los bordes de la ventana de visualización. La mayoría de los equipos subestiman ese trabajo y lanzan algo ligeramente defectuoso.

Radix es la base sobre la que se construye shadcn/ui, mientras que Headless UI es mantenido por el equipo de Tailwind. El costo obvio es que debes escribir todo el estilo tú mismo, lo cual es precisamente el objetivo, pero sigue siendo un trabajo real.

PrimeReact: amplitud para componentes inusuales

PrimeReact (v11.1.0 en el momento de redactar) pertenece a la familia PrimeFaces, que también incluye Angular, Vue y Java:

npm install primereact

Ofrece una amplia gama de funcionalidades, desde gráficos y organigramas hasta tablas en forma de árbol, programadores de tareas, widgets de carga y un conjunto completo de elementos de entrada, muchos de los cuales otras bibliotecas omiten por completo. Cuando necesites algo inusual, merece la pena verificarlo primero aquí.

Verifica tú mismo su licencia antes de adoptarlo. Sus metadatos de npm apuntan a un archivo de licencia (“SEE LICENSE IN LICENSE.md”) en lugar de proporcionar un identificador SPDX, y el proveedor también ofrece temas y plantillas de pago además del paquete gratuito. La biblioteca principal es de código abierto, pero lee los términos reales antes de crear un producto comercial con ella.

Tres más que merecen una mirada

• Chakra UI (v3.37.0, MIT) da prioridad a la accesibilidad y estila los componentes mediante propiedades; se sitúa entre el enfoque integral de MUI y las primitivas básicas de Radix.
• daisyUI (v5.7.34, MIT) es un plugin de Tailwind que proporciona clases de componentes en lugar de componentes React, lo que significa que también puede utilizarse con Svelte, Vue o marcado estático.
• HeroUI (v3.2.4, MIT), el sucesor rebautizado de NextUI, combina Tailwind con React Aria.

Una guía rápida para tomar decisiones

Para la interfaz de escritorio:

• Un ecosistema probado, una renderización idéntica en todas partes y un equipo que solo trabaja con JavaScript apuntan a Electron.
• Descargas pequeñas, bajo consumo de memoria, un modelo de seguridad más estricto o como objetivo móvil apuntan a Tauri.

Una capa ligera alrededor de una interfaz web existente apunta a Neutralino.

Si se desea tener Node y el DOM en un mismo contexto compartido, entonces NW.js es la opción.

En cuanto a las bibliotecas de componentes:

• Si se necesita casi cada tipo de componente además de una excelente documentación, MUI es la mejor opción.
• Si se quiere tener el control total y poder modificar el código en un proyecto Tailwind, shadcn/ui es la solución.
• Para pantallas empresariales con muchos datos, Ant Design es la opción adecuada.
• Si se buscan valores por defecto buenos sin opiniones demasiado fuertes, Mantine es la elección.
• Si se necesita un sistema de diseño personalizado con funcionalidades de accesibilidad ya integradas, Radix o Headless UI son las opciones.
• Para componentes especializados e inusuales, PrimeReact es la solución.

Hay una regla que anula toda la lista: si su equipo ya domina bien uno de estos herramientas, esa experiencia casi siempre supera a una opción ligeramente mejor en otro lugar.

Conclusión

En ambos niveles, las listas de características han convergido en gran medida; estos proyectos han tenido años para copiar las buenas ideas del otro. La cuestión del tamaño es donde aún difieren de manera perceptible para los usuarios. Electron frente a Tauri plantea el problema del tamaño para toda la aplicación: ¿empaquetar un navegador y obtener previsibilidad, o utilizar el que ofrece el sistema operativo para obtener un paquete veinte veces más pequeño? Elegir entre MUI y shadcn/ui aplica ese equilibrio al nivel de componentes: ¿confiar en un sistema de diseño completo mantenido por otros, o adquirir solo las piezas que se necesitan y mantenerlas uno mismo? Decida de qué lado está su producto en ese equilibrio antes de comenzar a comparar las tablas de características, y la lista final suele elegirse por sí sola.

Lecturas relacionadas

• Más allá del tamaño del bundle: descubriendo lo que realmente hace lenta su aplicación web — Por qué reducir kilobytes rara vez soluciona un problema de lentitud en la aplicación, y cómo rastrear el tiempo real de espera a través de servidores, procesos en cascada, scripts y imágenes de terceros.
• Comparativa de frameworks de superficie en JavaScript: Electron, Tauri, Electrobun, Deno — Compara los frameworks de superficie Electron, Tauri, Electrobun y Deno en términos de rendimiento, tamaño y seguridad para ayudarlo a elegir el framework de JavaScript adecuado en 2026.