Dart/Flutter now has macros/metaprogramming

Original Article ↗ Hacker News Discussion ↗

Dart is introducing an experimental macros and metaprogramming system, similar to Java’s annotation processors, aimed at replacing much of the boilerplate-heavy code generation currently common in Flutter and server-side Dart projects. Participants weigh the potential gains in performance and developer experience against familiar concerns about macro complexity, compile-time bloat, and maintainability. The conversation broadens into Dart’s position in the language ecosystem—its strengths in tooling, typing, and Flutter-based cross‑platform UI versus weaknesses in non-Flutter libraries, Flutter’s performance (especially on web and with embedded platform views), and uncertainty about Google’s long-term commitment compared to alternatives like Kotlin/Compose and TypeScript.

Macro feature and status

  • Linked repo is a demo; the authoritative spec is in the Dart language repo.
  • Macros are still experimental/alpha, not GA, but already in the SDK master branch.
  • They are compile‑time, closer to Java’s annotation processors than runtime reflection.
  • Intended to replace much of today’s code generation and integrate better with the compiler/AST.

Code generation, reflection, and tooling

  • Current Dart/Flutter workflows rely heavily on codegen (.g.dart, build_runner), which some find clunky and easy to get stale in CI.
  • Macros should run in memory before compilation and avoid checked‑in generated files, potentially improving performance and developer experience.
  • Concerns about macros in general: risk of unreadable macro‑heavy code, longer compile times, and “two languages.”
  • Counterpoint: Dart macros are written in normal Dart; there is no separate macro language.

Dart’s language role

  • Praised for instant compilation, strong static typing, null safety, and tooling.
  • Compared to alternatives:
    • vs Rust/Go: Dart has GC and exceptions.
    • vs JavaScript/TypeScript: Dart is statically typed, without JS’s legacy quirks.
  • Many see Dart’s primary value as its tight integration with Flutter, though some use it full‑stack and for servers.

Ecosystem, web, and upcoming features

  • Common view: ecosystem is rich enough for many needs but still weaker than JS, Python, or JVM languages, especially outside Flutter.
  • Some want Dart as a serious alternative to TypeScript for web apps; others doubt it will surpass TS’s type expressiveness.
  • New web APIs and Wasm support plus a shared‑memory multithreading proposal are mentioned as promising directions.

Flutter performance and UX

  • Strong disagreement over performance:
    • Many report smooth, efficient apps on mobile/desktop (especially with Impeller renderer).
    • Others describe high CPU usage (e.g., Cupertino text fields, web demos, platform views like ads or webviews) and janky scrolling, especially on iOS and web.
  • Consensus that Flutter web is less mature and performant than native targets; not ideal if web is the primary platform.

Alternatives and longevity concerns

  • Kotlin/Compose Multiplatform is discussed as a rising competitor with better native view interoperability but is still alpha and rough.
  • Several express concern about Google’s long‑term commitment to Dart/Flutter and to Fuchsia, while others argue recent adoption contradicts a “dying” narrative.