An update on Dart macros and data serialization

Overall reaction to canceling macros

• Many see the decision as mature engineering: better to cancel an over-ambitious feature than ship something slow and fragile.
• Some are disappointed about the lost effort and enjoyed previous reflection-based approaches, but agree the tradeoffs (size, speed, complexity) weren’t worth it.
• Several commenters explicitly say they trust the project more when it can say “no” even after significant sunk cost.

Macros vs alternative metaprogramming approaches

• Debate over whether Lisp-style macros still justify their complexity, given modern alternatives: code generation tools, preprocessors, templates, compile-time reflection, LLVM-based codegen.
• Pro‑macro voices argue a few hundred lines of macros can replace thousands of lines of custom generators and brittle build integrations.
• Anti‑macro voices say truly complex generation is better expressed as standalone tools and that macros sit in an awkward middle ground that is shrinking.
• Rust is cited as a language where macros “work well,” and Haxe as an example of balancing macros with hot reload.

Performance, hot reload, and build tooling

• Core technical blocker: semantic macros slowed compilation enough to noticeably degrade stateful hot reload, which developers expect in the low‑millisecond range.
• Some question whether such strict latency requirements are necessary; Dart/Flutter folks respond that extensive UX research shows hot-reload speed is a critical part of developer satisfaction.
• Current codegen via build_runner is widely viewed as slow and awkward (multi‑minute runs on real projects), though others report acceptable performance with careful configuration.
• There is active work to improve build_runner performance and make codegen more incremental and better integrated with IDEs.

Data modeling and serialization

• Strong desire for first-class “data class”/record support with features like copyWith and built-in serialization, without heavy annotation + codegen stacks.
• Existing Dart records are seen as insufficient for typical app needs; most rely on libraries like freezed.
• Several expect the team to deliver targeted features (data classes, serialization APIs, augmentations/partial classes) instead of a general macro system; a community “Codable”-style proposal is highlighted.

Tree shaking, reflection, and size

• Question about what “tree-shakeable” really means in Dart; explanation describes multi‑phase tree shaking on an intermediate IR and at AOT binary generation by walking a root set and discarding unused code.
• Exact behavior for dart2js and practical guidance on patterns that inhibit tree-shaking are noted as unclear and a source of confusion.
• Reflection/runtime introspection is repeatedly mentioned as problematic for aggressive tree shaking and small binaries.

Language choice for Flutter/Dart (C#, Go, TS, etc.)

• Some argue Flutter should have used C# to inherit a larger ecosystem and better data/codegen features.
• Others counter with historical context: in 2014–2015, .NET Core/Xamarin were immature, Go binaries were too large, JS/TS had bad iOS startup, Swift was Apple‑bound.
• Dart is praised as a pleasant, productive language with excellent Flutter hot reload; several note .NET hot reload and cross‑platform stories still lag for rich client apps.
• Broader C# discussion ensues (ecosystem strength, typing model vs TypeScript, cross‑platform limits), but there’s no consensus that it would have been clearly superior for Flutter.