Electron: qué es y por qué pesa tanto en RAM

⏱️ Lectura: 12 min

Un clip de 15 segundos acumuló 2,3 millones de vistas esta semana: el cliente nuevo de Discord, escrito en Rust, carga la lista de amigos antes de que la versión actual, hecha en Electron, termine de mostrar su pantalla de carga. Ambos arrancaron en frío, en la misma laptop, al mismo tiempo. Según el video que compartió el CTO de Discord, Stanislav Vishnevskiy, el cliente nuevo usa apenas 290 MB de RAM con dos cuentas activas al mismo tiempo.

📑 En este artículo

1. TL;DR
2. ¿Qué es Electron?
3. Por qué el framework de Electron pesa tanto en RAM
4. Cómo funciona Electron por dentro
5. Ejemplos prácticos: tu primera app con el framework de Electron
6. Cómo empezar
7. Comparativa: Electron, Tauri y WebView2
8. Casos de uso reales
9. Errores comunes y buenas prácticas
10. Profundizando
11. Preguntas frecuentes
    1. ¿Electron es lo mismo que un navegador embebido?
    2. ¿Por qué Discord cambió de Electron a un cliente propio en Rust?
    3. ¿Tauri reemplaza por completo a Electron?
    4. ¿Qué apps usan WebView2 en vez de Electron?
    5. ¿Cuánta RAM ahorra realmente cambiar de Electron a Tauri?
12. Referencias
    1. 📚 Artículos relacionados

Para entender por qué eso es noticia hay que mirar primero qué es el framework de Electron y por qué cada aplicación que lo usa, desde Discord hasta Slack y VS Code, termina arrastrando un navegador entero adentro. Y qué alternativas, como Tauri o WebView2, existen para no pagar ese precio en memoria.

TL;DR

• Electron empaqueta un Chromium y un Node.js completos en cada app, por eso pesa cientos de MB en reposo.
• El cliente Rust de Discord usa 290 MB con dos cuentas activas, unos 70% menos que el 1-2 GB habitual.
• Tauri cambia Chromium por el motor nativo del sistema y reduce el binario final a pocos megabytes.
• contextBridge aísla el renderer de Node.js sin bloquear la comunicación entre procesos.
• Migrar de Electron a Tauri o WebView2 implica reescribir la capa nativa, no solo cambiar el empaquetado.

¿Qué es Electron?

Electron es un framework de código abierto, lanzado por GitHub en 2013, para crear aplicaciones de escritorio con HTML, CSS y JavaScript. Cada programa construido con el framework de Electron empaqueta su propia copia de Chromium y de Node.js, lo que explica por qué estas apps pesan tanto en RAM frente a una app nativa.

La idea original era simple: si ya sabés hacer una web, podés empaquetarla como app de escritorio sin aprender Swift, C++ o C#. Electron nació dentro de GitHub para construir el editor Atom, y hoy lo usan VS Code, Slack, Notion, WhatsApp Desktop y, hasta ahora, Discord.

Por qué el framework de Electron pesa tanto en RAM

Un navegador normal (Chrome, Edge, Firefox) corre una sola vez en tu sistema y todas las pestañas comparten ese único proceso base. El framework de Electron no comparte nada entre apps: cada aplicación trae su propio Chromium empotrado, con su propio motor de JavaScript V8, su propio compositor gráfico y su propio runtime de Node.js para acceder al sistema de archivos o a la red.

Si tenés Discord, Slack y VS Code abiertos a la vez, no estás corriendo tres apps livianas: estás corriendo tres copias completas de Chromium en paralelo, cada una con su propio consumo base de memoria antes de renderizar un solo píxel de interfaz. Para confirmarlo, abrí el Administrador de tareas de Windows, buscá el ejecutable de la app (por ejemplo Discord.exe) y expandí la entrada: vas a ver un proceso padre y varios procesos hijos, uno por ventana o por pestaña interna que la app abra. Ese árbol es Chromium multiplicándose dentro de tu RAM.

Según el reporte de Windows Latest, un empleado de Discord había señalado en diciembre de 2025 que el uso normal de la app en Electron se mantiene bajo 1 GB, y que la compañía probaba reiniciarla automáticamente al llegar a 4 GB. Los 290,2 MB del cliente nuevo, con dos sesiones activas, quedan alrededor de 70% por debajo de ese piso de 1 GB.

Cómo funciona Electron por dentro

Electron separa su ejecución en dos tipos de proceso. El proceso main corre en Node.js puro, tiene acceso completo al sistema operativo (archivos, red, menús nativos) y es el único que puede crear ventanas. Cada ventana abre a su vez un proceso renderer, que es básicamente una pestaña de Chromium aislada, sin acceso directo a Node.js por razones de seguridad.

La comunicación entre ambos pasa por IPC (paso de mensajes entre procesos). Para que el renderer pida algo al main sin exponerle todo Node.js, Electron recomienda un preload script con contextBridge, que expone solo las funciones puntuales que la interfaz necesita.

graph TD
    A["Proceso main (Node.js)"] --> B["Renderer: ventana 1 (Chromium)"]
    A --> C["Renderer: ventana 2 (Chromium)"]
    B -. "IPC" .-> A
    C -. "IPC" .-> A

El modelo de procesos oficial de Electron detalla esta separación. Cada flecha punteada del diagrama es una llamada de ipcRenderer.invoke en el renderer que el main responde con ipcMain.handle.

sequenceDiagram
    participant R as Renderer (HTML/JS)
    participant P as Preload (contextBridge)
    participant M as Main (Node.js)
    R->>P: window.api.obtenerVersion()
    P->>M: ipcRenderer.invoke("obtener-version")
    M-->>P: process.versions.electron
    P-->>R: Promise resuelta con la version

Ejemplos prácticos: tu primera app con el framework de Electron

Esta app abre una ventana, carga un HTML simple y le pasa un dato del proceso main al renderer sin exponer Node.js directamente. Primero el proceso main, en main.js:

const { app, BrowserWindow, ipcMain } = require('electron');

function crearVentana() {
  const ventana = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: __dirname + '/preload.js',
      contextIsolation: true,
      nodeIntegration: false
    }
  });
  ventana.loadFile('index.html');
}

ipcMain.handle('obtener-version', () => process.versions.electron);

app.whenReady().then(() => {
  crearVentana();
  console.log('App lista, ventana creada');
});

Al correr npm start, la terminal imprime literalmente App lista, ventana creada y se abre una ventana de 800×600 píxeles. Ahora el preload.js, el único archivo con un pie en Node.js y otro en el navegador:

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('api', {
  obtenerVersion: () => ipcRenderer.invoke('obtener-version')
});

Y el renderer, que corre dentro del HTML sin ver Node.js en ningún momento:

window.api.obtenerVersion().then((version) => {
  document.getElementById('version').textContent = `Electron ${version}`;
});

El texto en pantalla cambia de vacío a algo como Electron 38.0.0 (la versión instalada en tu máquina). Esa es exactamente la separación que describe la documentación de context isolation: el HTML nunca toca require(), solo llama a la función puntual que el preload decidió exponer.

Cómo empezar

Dependencias necesarias: Node.js 18 LTS o superior y npm (viene incluido con Node). Los comandos son idénticos en Windows (PowerShell o cmd), macOS y Linux, porque npm no cambia entre sistemas.

mkdir hola-electron
cd hola-electron
npm init -y
npm install --save-dev electron
npm pkg set main=main.js
npm pkg set scripts.start="electron ."

Después creás main.js, preload.js e index.html con el código de la sección anterior, y corrés:

npm start

Salida esperada: se abre una ventana de 800×600 con el texto Hola Electron y, debajo, la versión instalada; en la terminal aparece la línea App lista, ventana creada.

Comparativa: Electron, Tauri y WebView2

flowchart TD
    subgraph Electron
    E1["Chromium propio"] --> E2["Node.js propio"]
    end
    subgraph Tauri
    T1["WebView del sistema"] --> T2["Backend en Rust"]
    end
    subgraph WebView2
    W1["Edge WebView2 compartido"] --> W2["Backend en C# o C++"]
    end

Casos de uso reales

VS Code, Slack, Notion y WhatsApp Desktop siguen corriendo sobre Electron hoy. El cliente actual de Discord también, aunque la empresa ya mostró en público su reemplazo en Rust: no es una app hecha con Tauri, es un motor propio, pero resuelve el mismo problema que Tauri ataca, evitar la copia duplicada de Chromium.

Microsoft, por su parte, reconstruyó la versión moderna de Teams usando WebView2 en vez de Electron: comparte el motor de renderizado de Edge que ya corre en el sistema en lugar de empaquetar uno propio. El ahorro no viene de un truco de configuración, viene de no cargar un segundo navegador completo por aplicación.

💭 Clave: ni Tauri ni WebView2 eliminan Chromium del todo: lo comparten entre apps en vez de duplicarlo. El ahorro de RAM viene de esa reutilización, no de un motor mágicamente más liviano.

Errores comunes y buenas prácticas

• nodeIntegration: true en el renderer: expone todo Node.js al HTML de la app, suficiente para que un script inyectado lea archivos o ejecute comandos del sistema.
• Omitir contextIsolation: sin aislamiento, el preload y la página comparten el mismo entorno de JavaScript y cualquier librería de terceros puede tocar las funciones expuestas.
• No cerrar BrowserWindow al terminar una tarea: cada ventana sin cerrar sigue corriendo su proceso Chromium completo en segundo plano.
• Actualizar Electron de forma esporádica: cada versión nueva trae los parches de seguridad de Chromium; quedarse atrás significa correr un navegador con vulnerabilidades ya conocidas.

Profundizando

Cada proceso renderer de Chromium reserva memoria para su propio heap de V8, su propio compositor gráfico y su propio sandbox de seguridad antes de interpretar una sola línea del HTML de la app. Ese costo base es independiente del contenido: una ventana vacía y una ventana con una interfaz compleja arrancan desde el mismo piso de memoria.

Tauri evita ese piso porque no trae su propio navegador: en Windows usa WebView2 (el mismo motor de Edge), en macOS usa WKWebView (WebKit) y en Linux usa WebKitGTK. El framework de Electron, en cambio, fija Chromium como único motor en los tres sistemas, lo que da consistencia visual total a cambio de pagar la RAM. Esa es justamente la contrapartida de Tauri: ganás tamaño y memoria, pero tu interfaz puede renderizar con pequeñas diferencias entre WebKit en macOS y WebView2 en Windows, algo que un equipo chico sin tiempo para QA multiplataforma puede no notar hasta que un usuario reporta un botón corrido.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: cloná el ejemplo de esta guía, corrélo con npm start y después abrí el Administrador de tareas para contar cuántos procesos hijos crea una sola ventana.

Preguntas frecuentes

¿Electron es lo mismo que un navegador embebido?

Es más que eso: además de Chromium como motor de renderizado, incluye un runtime completo de Node.js para que la app acceda a archivos, red y APIs del sistema operativo, algo que un navegador normal no permite a una página web.

¿Por qué Discord cambió de Electron a un cliente propio en Rust?

Según el reporte de Windows Latest, el objetivo fue eliminar la pantalla de carga de 5 a 10 segundos y bajar el consumo de RAM; el equipo de Discord confirmó que el nuevo cliente, de nombre interno Phoenix, se actualiza en segundo plano sin ese paso.

¿Tauri reemplaza por completo a Electron?

No en todos los casos: Tauri exige escribir la lógica nativa en Rust y tiene menos plugins listos que Electron, así que conviene para proyectos nuevos donde el tamaño importa desde el inicio, no necesariamente para migrar una app Electron grande y ya madura.

¿Qué apps usan WebView2 en vez de Electron?

La versión moderna de Microsoft Teams es el ejemplo más conocido: reutiliza el motor de Edge que el sistema Windows ya tiene corriendo en vez de empaquetar un Chromium propio.

¿Cuánta RAM ahorra realmente cambiar de Electron a Tauri?

No hay una cifra universal: depende de cuántas ventanas abra la app y de qué tan pesada sea su interfaz. Lo verificable es el mecanismo, no reservar un segundo motor de navegador, y eso se confirma mirando el árbol de procesos en el Administrador de tareas o en Activity Monitor.

Referencias

• Windows Latest: reporte sobre el cliente Rust de Discord y su consumo de RAM frente a Electron.
• Documentación oficial de Electron: modelo de procesos main y renderer.
• Documentación oficial de Electron: context isolation y contextBridge.
• Tauri: sitio oficial del framework que usa el webview nativo del sistema.
• Microsoft Learn: documentación oficial de WebView2.
• Wikipedia: historia y origen del framework de Electron en GitHub.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Fotis Fotopoulos en Unsplash