La pregunta que todo equipo Flutter se hace en 2026: ¿adiós a los .g.dart?
Si trabajas con Flutter, conoces el ritual: defines un modelo, anotas la clase, ejecutas build_runner, y aparece un fichero *.g.dart generado que no debes tocar. Multiplica eso por decenas de modelos y tienes un proyecto lleno de código generado, builds más lentos y un paso extra en cada cambio.
Durante un par de años, la promesa para resolver esto fue las macros de Dart: metaprogramación que generaría ese código en el propio compilador, sin ficheros intermedios. En 2026 esa promesa cambió de forma. La respuesta directa, para que decidas tu estrategia: las macros no van a llegar en el futuro previsible, pero sí llegan dos cosas concretas que mejoran el día a día —primary constructors y augmentations— además de mejoras específicas para serialización. Este artículo explica qué es real hoy, qué es experimental y qué no deberías esperar todavía.
Por qué se cancelaron las macros (y por qué es una buena noticia)
El equipo de Dart fue inusualmente transparente al respecto. Las macros no se cancelaron por falta de interés, sino por un conflicto fundamental con la identidad de Dart: el hot reload.
Las razones concretas que dieron:
- Coste de compilación elevado. Las macros introducían un coste en tiempo de compilación que hacía difícil "mantener caliente" el stateful hot reload —exactamente la característica que hace agradable desarrollar en Flutter.
- Rendimiento de edición. Análisis estático y autocompletado se ralentizaban.
- Compilación incremental. El primer paso del hot reload sufría retrasos.
- Convergencia incierta. El equipo concluyó que estaba "demasiado lejos" de poder enviar macros con el rendimiento de desarrollo que exigen.
La lectura honesta: el equipo prefirió no degradar la experiencia de desarrollo de millones de personas a cambio de una característica potente pero costosa. Para un CTO, esto es una señal de madurez del ecosistema, no de estancamiento. Es la diferencia entre un lenguaje que persigue features llamativas y uno que protege lo que ya funciona.
Lo que SÍ llega: tres cosas concretas
En lugar de una solución mágica de metaprogramación, Dart se ha decantado por mejoras específicas y predecibles.
1. Private Named Parameters (estable en Dart 3.12)
Ya es estable. Permite declarar campos privados con nombres de parámetro públicos sin la típica lista de inicializadores repetitiva. Es un pulido ergonómico pequeño pero que aparece en casi todas las clases.
2. Primary Constructors (experimental en Dart 3.12)
La característica más pedida. Permite declarar la clase y su constructor a la vez, recortando el boilerplate de los modelos de datos:
// Antes
class Point {
final int x;
final int y;
const Point(this.x, this.y);
}
// Con primary constructors
class Point(final int x, final int y);
El propio equipo lo etiqueta como experimental y pide feedback de uso real antes de estabilizarlo. Traducción para producción: pruébalo en una rama o en un proyecto interno, no migres todavía tus modelos críticos.
3. Augmentations
Augmentations es la pieza más interesante para el problema de los .g.dart. Se prototipó durante el trabajo de macros y se está sacando como característica de lenguaje independiente. La idea: el código generado aumenta la clase original en su sitio, en lugar de vivir en un fichero .g.dart separado que tienes que coser con part.
Importante gestionar la expectativa: augmentations no es macros. No te da introspección semántica profunda ni elimina la generación de código por sí sola. Lo que mejora es lo desordenado que resulta convivir con el código generado. build_runner no desaparece; se vuelve menos intrusivo.
Y para serialización: features "a medida"
Dado que el motivo número uno para querer macros era la serialización/deserialización (JSON), el equipo ha dicho que abordará ese caso con características de lenguaje específicas y a medida, en lugar de con un mecanismo genérico. Es un cambio de filosofía: resolver el problema concreto bien, en vez del problema general a medias.
Tabla: qué esperar y cuándo
| Característica | Estado 2026 | ¿Usar en producción ya? |
|---|---|---|
| Private named parameters | Estable (Dart 3.12) | Sí |
| Primary constructors | Experimental | No (pruebas internas) |
| Augmentations | En desarrollo como feature independiente | Todavía no |
| Macros | Canceladas (sin fecha previsible) | No esperar |
| Serialización "bespoke" | Anunciada, sin fecha | No esperar aún |
Cuándo NO cambiar tu forma de trabajar todavía
Es tentador reescribir modelos en cuanto sale una característica nueva. Recomendación sobria:
- No reescribas tus modelos de producción con primary constructors mientras sigan siendo experimentales. Un cambio de sintaxis del lenguaje en estado experimental puede variar antes de estabilizarse.
- No desmontes tu pipeline de
build_runneresperando que augmentations lo sustituya. Por ahora lo complementa, no lo reemplaza. - No bloquees decisiones de arquitectura esperando a las macros. No van a llegar; diseña con las herramientas actuales (
freezed,json_serializable,build_runner), que siguen siendo el estándar de facto. - Sí merece la pena empezar a usar private named parameters donde aporten claridad, y montar una rama de exploración con primary constructors para que tu equipo se familiarice.
Qué significa esto para tu equipo y tu producto
Para un responsable de producto o un CTO, la conclusión práctica es tranquilizadora: tu stack Flutter actual no queda obsoleto. La generación de código con build_runner, freezed y json_serializable sigue siendo la vía correcta en 2026. Lo que cambia es la dirección: Dart está reduciendo fricción de forma incremental y predecible, en lugar de apostar por una gran característica que pusiera en riesgo el hot reload.
Esa previsibilidad es, precisamente, lo que hace de Dart una apuesta segura para producto a largo plazo: pocas sorpresas, ergonomía en mejora continua y un equipo de lenguaje dispuesto a cancelar públicamente algo en lo que invirtió años cuando los números no salían.
Conclusión
Las macros eran la solución elegante sobre el papel, pero chocaban con lo que hace especial a Flutter. En 2026, Dart cambia ambición por pragmatismo: private named parameters ya estable, primary constructors en pruebas, augmentations para hacer menos molesto el código generado y mejoras de serialización a medida en el horizonte. Ninguna es revolucionaria por separado; juntas señalan un lenguaje que madura cuidando su mejor activo, el ciclo de desarrollo.
En Dribba escribimos Dart a diario en apps en producción y seguimos de cerca cada cambio del lenguaje para saber qué adoptar ya y qué dejar madurar. Si quieres una segunda opinión técnica sobre la arquitectura de datos de tu app Flutter, hablemos.
Lecturas relacionadas en el blog de Dribba: Dart full-stack en 2026 vs backend en Go, Arquitectura limpia en Flutter y State management en Flutter: Riverpod vs Bloc.
