Deja Electron y usa Wails: apps de escritorio con Go en 2026

Si estás creando una herramienta interna, un cliente de bases de datos, un visor de logs o cualquier app de escritorio pequeña o mediana, hazla con Wails en lugar de Electron. Wails combina un backend en Go con el webview que ya trae el sistema operativo, así que una app vacía pesa unos 8 a 11 MB en vez de 295 a 384 MB (benchmark de Elanis, 2026). Conservas tu frontend web y cambias Node por Go. El IPC escrito a mano pasa a ser bindings generados, y no hay Chromium empaquetado porque el webview lo pone el sistema operativo. Eso sí, Wails no gana todos los benchmarks, y para algunas apps Electron sigue siendo la mejor opción.

Resumen rápido

• El tamaño es la victoria clara. En un benchmark de apps vacías ejecutado en CI, los builds de Wails eran entre 30 y 40 veces más pequeños que los de Electron en Windows, macOS y Linux (benchmark de Elanis, 2026).
• En memoria y arranque no hay victoria total. Wails usó menos memoria en macOS y Linux, pero más en Windows, y Electron arrancó más rápido en los tres sistemas operativos en ese mismo benchmark.
• Las mayores ventajas son estructurales. Distribuyes un único binario de Go, escribes el backend con la biblioteca estándar de Go y goroutines, lo llamas mediante bindings tipados y generados, y no ejecutas Node en la página.
• Dejas de perseguir las versiones mayores de Electron. Electron publica una versión mayor nueva cada 8 semanas y solo da soporte a las tres últimas (Electron, 2026). Con Wails, el webview se parchea fuera de tu app: con el actualizador Evergreen de WebView2 en Windows (Microsoft Learn, 2026), con las actualizaciones de macOS y con los paquetes de tu distribución de Linux.
• Electron sigue siendo la opción correcta cuando necesitas un renderizado de Chromium idéntico en todas partes, dependes de módulos nativos de Node o ya tienes una gran base de código en Electron.

¿Qué incluye Electron en cada app?

Cada app de Electron lleva su propio navegador y su propio runtime de JavaScript. La documentación de Electron lo dice así: «Al integrar Chromium y Node.js en su binario, Electron te permite mantener una única base de código JavaScript» para todas las plataformas (documentación de Electron, 2026). Ese compromiso tenía sentido cuando la alternativa eran tres bases de código nativas. También significa que cada app que instalas incluye una copia completa de Chromium.

El modelo de procesos también viene de Chromium. Hay un proceso principal que ejecuta Node.js, más «un proceso de renderizado independiente para cada BrowserWindow abierta (y cada contenido web embebido)» (modelo de procesos de Electron, 2026). La lógica del backend vive en el proceso principal, la interfaz vive en los procesos de renderizado, y los conectas con mensajes IPC que escribes a mano.

Luego está el calendario de versiones. «La cadencia de Electron entre versiones mayores es de 8 semanas», y solo se da soporte a las tres últimas versiones mayores estables (calendario de Electron, 2026). Electron 44.0.0 pasó a estable el 25 de agosto de 2026, con Chromium M152 y Node v24.18.1. Electron 45 está previsto para el 20 de octubre de 2026 (versiones de Electron, 2026). Para que los parches de seguridad de Chromium lleguen a tus usuarios, tienes que seguir publicando builds nuevos a ese ritmo.

¿Cómo funciona Wails?

Wails se describe a sí mismo como «una alternativa a Electron ligera y rápida para Go» (documentación de Wails, 2026). En lugar de empaquetar un navegador, «reutiliza el motor de renderizado nativo de la plataforma». El README lo resume así: «Usa motores de renderizado nativos, ¡sin navegador embebido!» (Wails en GitHub, 2026). El motor depende del sistema operativo:

• Windows renderiza tu interfaz con Microsoft WebView2.
• macOS la renderiza con WebKit.
• Linux la renderiza con WebKitGTK.

Una app de Wails es «una aplicación Go estándar, con un frontend webkit» (Cómo funciona Wails, 2026). Tu frontend (React, Svelte, Vue o HTML sin más) se incrusta en el binario de Go con //go:embed, así que toda la app se distribuye como un único ejecutable.

El puente entre las dos mitades es la opción Bind, que «especifica qué métodos de struct se exponen al frontend». Cuando ejecutas wails dev, Wails lee esos métodos y genera wrappers de JavaScript junto con declaraciones de TypeScript. Tu frontend llama a los métodos de Go como si fueran funciones async. Para enviar datos en sentido contrario, Go emite eventos del runtime y JavaScript los escucha.

Wails v2 es la línea estable, y la v2.14.0 salió el 10 de agosto de 2026 (versiones de Wails, 2026). El proyecto tiene licencia MIT y unas 36.300 estrellas en GitHub. Entre las apps construidas con él están Tiny RDM, una GUI para Redis con unas 13.000 estrellas (Tiny RDM, 2026), y el cliente gRPC Wombat (escaparate de Wails, 2026).

Wails vs Electron: ¿cuánto más pequeña y ligera es la app?

Mucho más pequeña, pero no siempre más ligera. Las mejores cifras públicas vienen de la comparativa de frameworks web a escritorio de Elanis, que compila una app vacía con cada framework en modo release en GitHub CI y mide el tamaño, la memoria y el arranque. Se actualizó el 4 de septiembre de 2026 (benchmark de Elanis, 2026).

Fuente: Elanis web-to-desktop-framework-comparison, actualizado el 2026-09-04. App vacía, build de release, GitHub CI. Compara frameworks solo dentro del mismo sistema operativo. El README no indica las versiones de los frameworks.

En tamaño, Wails gana sin discusión. Una app vacía de Wails es unas 35 veces más pequeña que una de Electron en Windows, 40 veces en macOS y 33 veces en Linux. Con la conexión lenta de un hotel, 11 MB se descargan en segundos y 384 MB tardan minutos. Y la cosa se acumula cuando cada herramienta del portátil lleva su propio Chromium.

La memoria depende del sistema operativo. En macOS, Wails usó unas 3,7 veces menos memoria que Electron. En Linux usó unas 1,6 veces menos. En Windows usó más, unos 323 MB frente a los 278 MB de Electron. El benchmark no lo desglosa, pero WebView2 usa el motor de Microsoft Edge, que está basado en Chromium, y ejecuta sus propios procesos de navegador. Así que en Windows probablemente sigues pagando en memoria por un motor Chromium, aunque no lo distribuyas tú.

En este benchmark, Electron arrancó más rápido en todas partes. En Windows se abrió en unos 206 ms frente a los 559 ms de Wails. En macOS la diferencia fue de 640 ms frente a 1.740 ms. En Linux los dos quedaron cerca, 204 ms frente a 263 ms. Una app vacía en un runner de CI da una idea aproximada y no coincidirá con lo que vean tus usuarios. Aun así, los datos no respaldan la idea de que Wails siempre arranca más rápido.

Una advertencia más sobre Windows. Las apps de Wails necesitan el Microsoft WebView2 Runtime. Viene incluido en Windows 11, y Microsoft afirma que «la inmensa mayoría de los dispositivos con Windows 10 ya tienen instalado el WebView2 Runtime» (Microsoft Learn, 2026). Incrustar el bootstrapper cubre el resto y añade unos 150 KB (guía de Windows de Wails, 2026). Pero si necesitas fijar la versión del motor, Microsoft advierte que «los binarios de la Fixed Version ocupan más de 250 MB y harán que el paquete de tu app crezca en esa misma cantidad». Eso se come la mayor parte de la ventaja de tamaño en Windows.

¿Cómo es el código de Wails?

Este es un pequeño visor de logs que podrías crear para tu equipo: eliges un archivo de log, muestras las últimas 200 líneas y luego vas transmitiendo las líneas nuevas a medida que se escriben. También hace ping al endpoint de salud de un servicio. Todo se ejecuta en Go, y el frontend solo renderiza.

La parte de Go es un struct normal con métodos exportados. TailLog lee un archivo con os y bufio. CheckHealth llama a un endpoint HTTP con un timeout usando net/http, que se trata en el curso de HTTP. El código de abajo compila contra Wails v2.14.0:

example.gogo
// app.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"net/http"
	"os"
	"sync"
	"time"
)

const tailLines = 200

type App struct {
	ctx        context.Context
	mu         sync.Mutex
	stopFollow context.CancelFunc
}

func NewApp() *App { return &App{} }

// startup is called by Wails once the app is running. Keep the context:
// runtime calls like EventsEmit need it.
func (a *App) startup(ctx context.Context) {
	a.ctx = ctx
}

// TailLog returns the last 200 lines of the log file at path.
func (a *App) TailLog(path string) ([]string, error) {
	f, err := os.Open(path)
	if err != nil {
		return nil, fmt.Errorf("open log: %w", err)
	}
	defer f.Close()

	lines := make([]string, 0, tailLines)
	sc := bufio.NewScanner(f)
	sc.Buffer(make([]byte, 0, 64*1024), 1024*1024) // allow long JSON log lines
	for sc.Scan() {
		if len(lines) == tailLines {
			lines = lines[1:]
		}
		lines = append(lines, sc.Text())
	}
	if err := sc.Err(); err != nil {
		return nil, fmt.Errorf("read log: %w", err)
	}
	return lines, nil
}

// CheckHealth calls a service's health endpoint and returns the status code.
func (a *App) CheckHealth(url string) (int, error) {
	ctx, cancel := context.WithTimeout(a.ctx, 3*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return 0, fmt.Errorf("build request: %w", err)
	}
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return 0, fmt.Errorf("health check %s: %w", url, err)
	}
	defer resp.Body.Close()
	return resp.StatusCode, nil
}

main incrusta el frontend compilado y pasa el struct a Bind. Wails v2 está en github.com/wailsapp/wails/v2:

example.gogo
// main.go
package main

import (
	"embed"
	"log"

	"github.com/wailsapp/wails/v2"
	"github.com/wailsapp/wails/v2/pkg/options"
	"github.com/wailsapp/wails/v2/pkg/options/assetserver"
)

//go:embed all:frontend/dist
var assets embed.FS

func main() {
	app := NewApp()

	err := wails.Run(&options.App{
		Title:  "Log Viewer",
		Width:  1100,
		Height: 720,
		AssetServer: &assetserver.Options{
			Assets: assets,
		},
		OnStartup: app.startup,
		Bind:      []interface{}{app},
	})
	if err != nil {
		log.Fatal(err)
	}
}

Ejecuta wails dev y Wails genera frontend/wailsjs/go/main/App.js y App.d.ts. Las declaraciones tienen este aspecto:

example.tsts
export function TailLog(arg1: string): Promise<Array<string>>;
export function CheckHealth(arg1: string): Promise<number>;

Cada método vinculado devuelve una Promise. Si el método de Go devuelve un error distinto de nil, la Promise se rechaza con él. Así que el frontend usa await y try/catch sin más:

example.tsts
import { TailLog, CheckHealth } from "../wailsjs/go/main/App";

async function openLog(path: string) {
  try {
    const lines = await TailLog(path);
    renderLines(lines);
  } catch (err) {
    showError(`Could not read ${path}: ${err}`);
  }
}

async function refreshStatus(url: string) {
  try {
    const status = await CheckHealth(url);
    setStatus(status === 200 ? "healthy" : `HTTP ${status}`);
  } catch (err) {
    setStatus(`down: ${err}`);
  }
}

No tienes que mantener sincronizados nombres de canal ni comprobar a mano la forma de los mensajes. Si cambias la firma de un método de Go, la declaración regenerada cambia con ella, así que un build del frontend con comprobación de tipos señala las llamadas que se han quedado desfasadas.

Transmitir líneas nuevas con eventos del runtime

Para seguir un archivo en vivo, la concurrencia de Go viene muy bien. FollowLog salta al final del archivo y luego una goroutine consulta periódicamente si hay líneas nuevas y envía cada una al frontend con runtime.EventsEmit. Abrir otro archivo cancela el seguimiento anterior:

example.gogo
// follow.go
package main

import (
	"bufio"
	"context"
	"fmt"
	"io"
	"os"
	"strings"
	"time"

	"github.com/wailsapp/wails/v2/pkg/runtime"
)

// FollowLog streams lines appended to path as "log:line" events.
func (a *App) FollowLog(path string) error {
	f, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("open log: %w", err)
	}
	if _, err := f.Seek(0, io.SeekEnd); err != nil {
		f.Close()
		return fmt.Errorf("seek log: %w", err)
	}

	a.mu.Lock()
	if a.stopFollow != nil {
		a.stopFollow()
	}
	ctx, cancel := context.WithCancel(a.ctx)
	a.stopFollow = cancel
	a.mu.Unlock()

	go a.follow(ctx, f)
	return nil
}

func (a *App) follow(ctx context.Context, f *os.File) {
	defer f.Close()

	r := bufio.NewReader(f)
	var partial strings.Builder
	ticker := time.NewTicker(500 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			for {
				chunk, err := r.ReadString('\n')
				partial.WriteString(chunk)
				if err != nil {
					break // no complete line yet, try again on the next tick
				}
				line := strings.TrimRight(partial.String(), "\r\n")
				runtime.EventsEmit(a.ctx, "log:line", line)
				partial.Reset()
			}
		}
	}
}

En el frontend, suscríbete una sola vez con EventsOn:

example.tsts
import { FollowLog } from "../wailsjs/go/main/App";
import { EventsOn } from "../wailsjs/runtime/runtime";

EventsOn("log:line", (line: string) => appendLine(line));

await FollowLog("/var/log/payments-api/app.log");

En Electron escribirías la misma funcionalidad con fs en el proceso principal, un ipcMain.handle para la lectura, un webContents.send por cada línea nueva y un script de preload que exponga ambos a través de contextBridge. En Wails es un struct de Go y un nombre de evento. Esta versión no gestiona la rotación de logs. Un seguimiento para producción volvería a abrir el archivo cuando su tamaño disminuya.

Wails v3 cambia un poco la estructura. Registras servicios en application.Options.Services con application.NewService(&LogService{}), y el frontend importa el código generado desde un directorio bindings en lugar de wailsjs (bindings de Wails v3, 2026). Lo que el frontend llama siguen siendo métodos de un tipo de Go.

¿En qué se diferencia el modelo de seguridad?

La seguridad de Electron depende de una lista de comprobación, y Wails parte de una superficie más pequeña. La propia guía de seguridad de Electron te pide que mantengas desactivada la integración de Node para contenido remoto (el valor por defecto desde la 5.0.0), que mantengas activado el aislamiento de contexto (por defecto desde la 12.0.0), que mantengas activado el sandboxing de procesos (por defecto desde la 20.0.0), que valides el remitente de cada mensaje IPC, que definas una Content Security Policy y que expongas APIs a la página solo a través de contextBridge (seguridad de Electron, 2026).

Esos valores por defecto hoy son buenos, pero cada uno es un flag que tu código puede desactivar. Y como cada app empaqueta Chromium, un fallo del navegador se queda en tu app instalada hasta que publicas una actualización basada en un Electron parcheado.

Wails elimina varios de esos puntos por diseño. No hay Node.js en la página, así que no hay nodeIntegration que configurar mal. La página recibe tus métodos de Go vinculados más la API del runtime de Wails, y nada más del sistema anfitrión. No puede leer archivos ni lanzar procesos a menos que uno de tus métodos lo haga. Como el webview pertenece al sistema operativo, sus parches de seguridad no pasan por tu pipeline de releases. Llegan con el runtime Evergreen de WebView2 en Windows, que se actualiza solo, con las actualizaciones de macOS o con los paquetes de tu distribución de Linux. Si fijas un runtime Fixed Version en Windows, los parches vuelven a ser cosa tuya.

Queda algo de riesgo. Cada método vinculado es una API, y la página que lo llama puede renderizar contenido que no controlas. En el visor de logs de arriba, TailLog acepta cualquier ruta. Si tu app llega a mostrar HTML no confiable, eso es una primitiva de lectura de archivos. Valida los argumentos en Go igual que validarías la entrada de un handler HTTP: limita las rutas a directorios permitidos y las URL a hosts conocidos. Una CSP también sigue importando, porque la página puede hacer peticiones de red como cualquier otra página del navegador.

Si te interesa la pregunta relacionada de qué puede hacer una dependencia de Node en el momento de instalarla, consulta ¿Es Go más seguro que Node.js en la cadena de suministro?.

¿Qué te cuesta Wails?

Wails cambia un navegador empaquetado por tres webviews distintos, y eso tiene costes. Microsoft indica que, con el Evergreen WebView2 Runtime, deberías preparar pruebas de compatibilidad futura, porque el motor se actualiza por debajo de tu app (Microsoft Learn, 2026). En macOS apuntas a WebKit, el motor de Safari, así que prueba allí cualquier CSS o API web que solo hayas comprobado en Chrome.

Linux es la plataforma más complicada. La guía de Linux de Wails enumera problemas conocidos: el evento ended de vídeo no se dispara por un bug de WebKitGTK, puede que veas «GStreamer element autoaudiosink not found», y «WebKit instala manejadores de señales que interfieren con el mecanismo de recuperación de panics de Go» (guía de Linux de Wails, 2026). También hay una división de ABI. Debian 11, Ubuntu 20.04 y RHEL 8 a 9 necesitan el WebKitGTK 4.0 heredado, así que eliges entre los build tags webkit2_41 y webkit2_40 (soporte de distribuciones de Wails, 2026). Un issue de la v3 de febrero de 2026 informa de una ventana en blanco en X11 con Nvidia, que se soluciona con WEBKIT_DISABLE_DMABUF_RENDERER=1 (issue #4985 de Wails, 2026).

Otros costes que conviene conocer:

• La v2 es de una sola ventana. La guía de migración a la v3 dice que la v2 «solo admitía una ventana por aplicación», mientras que la v3 «introduce soporte nativo para múltiples ventanas como funcionalidad central» (guía de v2 a v3 de Wails, 2026).
• La v3 sigue en beta. La última es la v3.0.0-beta.25, del 22 de septiembre de 2026. Sus notas de versión dicen: «La API es estable, pero aún puedes encontrarte problemas antes de la versión final 3.0» (versiones de Wails, 2026). La guía de migración añade que «la v2 sigue siendo la versión estable actual».
• El ecosistema es más pequeño. Hay menos plugins, y cuando te topas con un bug raro es menos probable que alguien ya haya documentado la solución.
• La documentación de migración es escasa. La página «desde Electron» de la documentación de la v3 es, por ahora, un marcador de posición.

¿Y Tauri?

Tauri es el otro gran framework basado en webview. Se describe como «un framework para crear binarios diminutos y rápidos para todas las principales plataformas de escritorio y móviles», usa «el web view que ya está disponible en el sistema de cada usuario» y tiene un backend en Rust (Tauri, 2026). Tauri 2.0 pasó a estable el 2 de octubre de 2024 (blog de Tauri, 2024).

En el benchmark de Elanis, Tauri generó los builds más pequeños (unos 3 a 5 MB) y usó la menor cantidad de memoria en Linux. También tuvo el arranque más lento en todos los sistemas operativos, incluidos unos 30 segundos en el runner de CI de Linux. Tauri y Wails comparten los mismos compromisos del webview, así que la elección se reduce sobre todo al lenguaje del backend. Si tu equipo escribe Rust, usa Tauri. Si tu equipo escribe Go, usa Wails.

¿Cómo migrar una app de Electron a Wails?

Conserva tu frontend y sustituye el proceso principal. Wails todavía no tiene una guía oficial de migración desde Electron, así que planifica el trabajo emparejando cada pieza de Electron con su equivalente en Go:

Un orden práctico:

1. Mueve el frontend tal cual. Apunta Wails a la salida de tu build actual de Vite o webpack. La mayoría de los componentes no necesitan cambios. Solo los puntos de llamada que hablan con la API del preload, y de eso se encarga el paso 2.
2. Porta un canal IPC cada vez. Cada ipcMain.handle se convierte en un método de Go. Borra la entrada correspondiente del preload y cambia el punto de llamada al import generado.
3. Sustituye los mensajes push por eventos. Todo lo que se envía con webContents.send pasa a ser runtime.EventsEmit.
4. Rehaz el empaquetado. wails build compila «un binario listo para producción», y flags como -nsis, -webview2 y -platform cubren instaladores, estrategia de WebView2 y compilación cruzada (CLI de Wails, 2026). La guía de firma cubre la notarización en macOS y SignTool en Windows, incluido GitHub Actions.
5. Prueba en los tres webviews. Este paso es trabajo nuevo respecto a Electron, así que resérvale tiempo.

El Go que escribes en el paso 2 es sobre todo código de la biblioteca estándar. Si os, net/http y encoding/json son nuevos para ti, el curso de HTTP y el curso de formatos de datos cubren las partes que usa un backend de escritorio.

Dónde encaja LevelUpGo

El visor de logs de arriba se apoya en los fundamentos de Go: funciones, múltiples valores de retorno, manejo de errores y la biblioteca estándar. El curso Go Basics de LevelUpGo los enseña con un editor real junto a cada lección, y tu código tiene que pasar los tests antes de avanzar. El trabajo con goroutines y context de FollowLog se trata en Concurrency Fundamentals. Cuando quieras practicar más, el Training Ground tiene ejercicios independientes.

Si todavía estás decidiendo si Go merece tu tiempo, empieza por ¿Vale la pena aprender Go en 2026?. Para ver dónde se usa ya Go en producción, lee ¿Dónde se usa Go?, y para la parte del servidor, El mejor lenguaje de programación para backend.

Preguntas frecuentes

¿Es Wails mejor que Electron?

Para la mayoría de apps de escritorio pequeñas y medianas, sí. En el benchmark de Elanis, una app vacía de Wails era entre 30 y 40 veces más pequeña que una app de Electron (benchmark de Elanis, 2026), y además tienes un backend en Go con bindings tipados. Electron sigue siendo mejor cuando necesitas un renderizado de Chromium idéntico o módulos nativos de Node.

¿Usa Wails menos memoria que Electron?

Depende del sistema operativo. En el mismo benchmark, Wails usó unos 100 MB frente a los 369 MB de Electron en macOS, y 360 MB frente a 586 MB en Linux. En Windows usó más, unos 323 MB frente a 278 MB, probablemente porque WebView2 usa el motor de Microsoft Edge, basado en Chromium, y ejecuta sus propios procesos de navegador.

¿Está Wails listo para producción?

Wails v2 es la versión estable, y la v2.14.0 salió el 10 de agosto de 2026 (versiones de Wails, 2026). Apps como Tiny RDM funcionan sobre ella. Wails v3 está en beta. Su documentación dice que hay aplicaciones en producción que ya la usan, pero recomienda probar a fondo antes de desplegar.

¿Funcionan las apps de Wails en Windows 10?

Sí, siempre que esté instalado el WebView2 Runtime. Microsoft afirma que la inmensa mayoría de los dispositivos con Windows 10 ya lo tienen (Microsoft Learn, 2026). Para el resto, Wails puede incrustar un bootstrapper o descargar el runtime durante la instalación con el flag de build -webview2.

¿Puedo mantener mi frontend de React al pasar a Wails?

Sí. Wails sirve cualquier frontend web compilado a partir de archivos incrustados en el binario de Go, así que React, Vue, Svelte y HTML sin más funcionan. Lo que cambia es cómo habla el frontend con el backend. Las llamadas IPC pasan a ser imports de funciones generadas, y los mensajes push pasan a ser eventos del runtime.

Fuentes

• Elanis, web-to-desktop-framework-comparison (actualizado el 2026-09-04)
• Wails, Introduction
• Wails en GitHub
• Wails, How does it work?
• Versión v2.14.0 de Wails
• Versión v3.0.0-beta.25 de Wails
• Wails v3, Migrating from v2
• Wails v3, Binding methods
• Referencia de la CLI de Wails
• Guía de firma de Wails
• Guía de Windows de Wails
• Guía de Linux de Wails
• Soporte de distribuciones Linux de Wails
• Issue #4985 de Wails, ventana en blanco en Linux X11 con Nvidia
• Escaparate de Wails
• Tiny RDM
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Documentación de Electron
• Electron, Process model
• Electron, Release timelines
• Calendario de versiones de Electron
• Electron, Security checklist
• Escaparate de apps de Electron
• Tauri, Start
• Anuncio de Tauri 2.0 (2024)