Dart/Flutter ahora tiene macros/metaprogramación
Dart está introduciendo un sistema experimental de macros y metaprogramación, similar a los procesadores de anotaciones de Java, destinado a reemplazar gran parte de la generación de código cargada de boilerplate que hoy es común en proyectos de Flutter y de Dart del lado del servidor. Los participantes evalúan las posibles mejoras en rendimiento y experiencia de desarrollo frente a preocupaciones conocidas sobre la complejidad de las macros, el aumento del tiempo de compilación y el mantenimiento. La conversación se amplía al lugar de Dart en el ecosistema de lenguajes: sus fortalezas en herramientas, tipado y UI multiplataforma basada en Flutter frente a sus debilidades en bibliotecas fuera de Flutter, el rendimiento de Flutter —especialmente en la web y con vistas de plataforma incrustadas— y la incertidumbre sobre el compromiso a largo plazo de Google, en comparación con alternativas como Kotlin/Compose y TypeScript.
Funcionalidad y estado de las macros
- El repositorio enlazado es una demostración; la especificación autoritativa está en el repositorio del lenguaje Dart.
- Las macros siguen siendo experimentales/alpha, no GA, pero ya están en la rama master del SDK.
- Son de tiempo de compilación, más parecidas a los procesadores de anotaciones de Java que a la reflexión en tiempo de ejecución.
- La intención es reemplazar gran parte de la generación de código actual e integrarse mejor con el compilador/AST.
Generación de código, reflexión y herramientas
- Los flujos de trabajo actuales de Dart/Flutter dependen mucho de la generación de código (
.g.dart,build_runner), que algunos consideran torpe y fácil de quedar desactualizada en CI. - Las macros deberían ejecutarse en memoria antes de la compilación y evitar archivos generados y confirmados en el repositorio, lo que potencialmente mejoraría el rendimiento y la experiencia de desarrollo.
- Preocupaciones sobre las macros en general: riesgo de código difícil de leer y muy cargado de macros, tiempos de compilación más largos y “dos lenguajes”.
- Contraargumento: las macros de Dart se escriben en Dart normal; no existe un lenguaje de macros separado.
El papel del lenguaje Dart
- Se elogia su compilación instantánea, tipado estático sólido, null safety y herramientas.
- Comparado con alternativas:
- frente a Rust/Go: Dart tiene GC y excepciones.
- frente a JavaScript/TypeScript: Dart está tipado estáticamente, sin las rarezas heredadas de JS.
- Muchos consideran que el valor principal de Dart está en su integración estrecha con Flutter, aunque algunos lo usan full-stack y para servidores.
Ecosistema, web y funciones próximas
- La opinión común: el ecosistema es lo bastante rico para muchas necesidades, pero sigue siendo más débil que JS, Python o los lenguajes JVM, especialmente fuera de Flutter.
- Algunos quieren que Dart sea una alternativa seria a TypeScript para aplicaciones web; otros dudan de que supere la expresividad tipada de TS.
- Se mencionan nuevas APIs web y compatibilidad con Wasm, además de una propuesta de multihilo con memoria compartida, como direcciones prometedoras.
Rendimiento y UX de Flutter
- Hay un fuerte desacuerdo sobre el rendimiento:
- Muchos informan de aplicaciones fluidas y eficientes en móvil/escritorio (especialmente con el renderizador Impeller).
- Otros describen alto uso de CPU (por ejemplo, campos de texto Cupertino, demos web, vistas de plataforma como anuncios o webviews) y desplazamiento entrecortado, especialmente en iOS y la web.
- Hay consenso en que Flutter web es menos maduro y menos eficiente que los destinos nativos; no es ideal si la web es la plataforma principal.
Alternativas y preocupaciones sobre la longevidad
- Kotlin/Compose Multiplatform se discute como un competidor en ascenso con mejor interoperabilidad con vistas nativas, pero sigue siendo alpha y áspero.
- Varios expresan preocupación por el compromiso a largo plazo de Google con Dart/Flutter y con Fuchsia, mientras que otros argumentan que la adopción reciente contradice la narrativa de que está “muriendo”.