Flutter 3.24, publicado en agosto de 2024, marcó un hito para Flutter Web: WebAssembly pasó a ser estable. Hasta entonces, el renderer de Flutter para web funcionaba con JavaScript (dart2js) o con CanvasKit cargado via JavaScript. Con Wasm como opción estable, la ecuación cambia. Pero antes de migrar todo, conviene entender qué ganas, qué pierdes y cuándo tiene sentido realmente.
Cómo funciona Flutter Web
Flutter Web tiene dos renderers principales:
- HTML renderer: usa elementos HTML y CSS del navegador. Tamaño de descarga pequeño, pero las limitaciones del DOM se notan.
- CanvasKit: usa Skia (o Impeller en el futuro) compilado a WebAssembly para dibujar en un canvas. El resultado visual es idéntico al nativo, pero el tamaño inicial de descarga es mayor (~2 MB de Wasm).
Desde Flutter 3.24, puedes compilar el runtime de Dart a Wasm directamente, lo que elimina la capa de traducción a JavaScript y ofrece mejor rendimiento en operaciones que dependen del runtime de Dart.
Compilar para WebAssembly
// Compilar con soporte Wasm (requiere Flutter 3.24+) flutter build web --wasm // Para desarrollo flutter run -d chrome --wasm
El requisito del navegador es importante: necesitas Chrome 112+ o Firefox 120+ con soporte para WasmGC (la extensión de WebAssembly que permite recolección de basura, necesaria para Dart). Safari tiene soporte desde la versión 18.2. En 2026, la cobertura de navegadores es suficientemente amplia para considerar Wasm en producción.
Qué ganas con Wasm
El beneficio principal está en el rendimiento de ejecución del código Dart, no necesariamente en el renderizado visual. Si tu app hace muchos cálculos en el lado cliente (procesamiento de datos, lógica de negocio compleja), la diferencia puede ser notable. El código Dart compilado a Wasm ejecuta más rápido que el equivalente en JavaScript generado por dart2js.
Además, la coherencia de comportamiento mejora: el mismo código Dart que corre en móvil corre en el navegador sin la capa de traducción a JS, lo que elimina una categoría de bugs que aparecían solo en web.
Qué no cambia (y lo que aún duele)
Wasm no resuelve el problema del tamaño inicial de descarga. Una app Flutter Web con CanvasKit+Wasm descarga entre 3 y 5 MB antes de mostrar nada. Para webs de contenido general donde el SEO importa y el usuario llega de una búsqueda, esto es un problema real.
Los motores de búsqueda pueden indexar páginas Flutter Web, pero el rastreo es más complejo que con HTML semántico. Si tu prioridad es el SEO o la accesibilidad estándar, Flutter Web no es la herramienta adecuada, independientemente de que uses Wasm o no.
Otro punto a tener en cuenta: los plugins de Flutter que usan APIs nativas del navegador (WebRTC, Bluetooth, ficheros) necesitan implementaciones específicas para web. No todos los plugins del ecosistema tienen soporte web completo.
Cuándo tiene sentido Flutter Web
Flutter Web con Wasm encaja bien en estas situaciones:
- Apps internas o herramientas de empresa donde el SEO no importa y los usuarios tienen navegadores modernos.
- Reutilizar lógica de negocio de una app móvil Flutter en web sin reescribir nada.
- Dashboards y herramientas interactivas con visualizaciones complejas donde la coherencia visual con la versión móvil es importante.
- Juegos y apps creativas donde se usa el canvas directamente y el renderizado es el protagonista.
Cuándo no tiene sentido
Si estás construyendo un sitio web de contenido, un e-commerce, un blog o cualquier cosa donde el SEO, los tiempos de carga y la accesibilidad semántica sean prioritarios, Flutter Web no es la elección correcta. Para eso, frameworks como Next.js, Astro o incluso WordPress hacen un trabajo mucho mejor.
También hay que ser realista con el ecosistema de plugins: si necesitas integrar Stripe, analytics, chat o cualquier SDK de terceros que espere estar en un entorno JavaScript/HTML estándar, tendrás que escribir código de adaptación específico para Flutter Web.
Estado actual del soporte Wasm en Flutter
En 2026, Flutter 3.27 continúa mejorando la estabilidad de Wasm en web. Los principales plugins de primera parte (firebase_core, google_maps_flutter) ya tienen soporte web. El tiempo de carga inicial sigue siendo el mayor punto de mejora pendiente, y el equipo de Flutter está trabajando en lazy loading de módulos Wasm para reducirlo.
// pubspec.yaml ejemplo de app Flutter multi-plataforma
dependencies:
flutter:
sdk: flutter
firebase_core: ^3.0.0 # soporte web incluido
firebase_auth: ^5.0.0 # soporte web incluido
flutter:
uses-material-design: true
Si ya tienes una app Flutter para móvil, añadir soporte web es viable y el overhead de mantenimiento no es grande si evitas depender de plugins sin soporte web. Si partes de cero y el objetivo principal es web, la elección depende de si tu caso de uso encaja en los escenarios donde Flutter Web aporta valor real.
Para el lado móvil de Flutter, merece la pena entender cómo funciona el nuevo motor de renderizado Impeller, del que hablamos en el artículo sobre Impeller y el renderizado en Flutter.
Imagen: Pexels / AS Photography