Dart/Flutter 现在有宏/元编程
Dart 正在引入一套实验性的宏和元编程系统，类似 Java 的注解处理器，目标是取代 Flutter 和服务端 Dart 项目中常见的大量样板式代码生成。参与者围绕宏在性能和开发体验上的潜在收益，与宏复杂度、编译期开销和可维护性等常见担忧展开讨论。讨论还扩展到 Dart 在语言生态中的位置——它在工具链、类型系统以及基于 Flutter 的跨平台 UI 方面的优势，与非 Flutter 库生态的不足、Flutter 的性能问题（尤其是 Web 和嵌入式平台视图），以及相较于 Kotlin/Compose 和 TypeScript 等替代方案时，对 Google 长期投入的担忧。
宏特性与状态
- 链接的仓库只是一个演示；权威规范在 Dart 语言仓库中。
- 宏仍处于实验性/alpha 阶段，尚未 GA，但已经在 SDK master 分支中。
- 它们在编译时运行，更接近 Java 的注解处理器，而不是运行时反射。
- 旨在取代当今大量的代码生成，并与编译器/AST 更好地集成。
代码生成、反射与工具链
- 当前 Dart/Flutter 工作流高度依赖代码生成（
.g.dart、build_runner），有些人觉得这很笨重，而且在 CI 中很容易过时。 - 宏应当在编译前以内存方式运行，并避免提交生成文件，从而有望提升性能和开发体验。
- 对宏的一般担忧包括：宏重度代码可能难以阅读、编译时间更长，以及“两个语言”的问题。
- 反驳观点：Dart 宏用普通 Dart 编写；并不存在单独的宏语言。
Dart 的语言角色
- 它因即时编译、强静态类型、空安全和工具链而受到称赞。
- 与其他方案相比：
- 对比 Rust/Go：Dart 有 GC 和异常。
- 对比 JavaScript/TypeScript：Dart 是静态类型的，没有 JS 的历史包袱和怪癖。
- 许多人认为 Dart 的主要价值在于与 Flutter 的紧密集成，不过也有人将其用于全栈和服务器端。
生态、Web 与即将到来的特性
- 普遍看法是：生态足以满足许多需求，但仍弱于 JS、Python 或 JVM 语言，尤其是在 Flutter 之外。
- 有人希望 Dart 成为 Web 应用中 TypeScript 的严肃替代品；也有人怀疑它无法超越 TS 的类型表达能力。
- 还提到了新的 Web API、Wasm 支持，以及共享内存多线程提案，认为这些方向很有前景。
Flutter 性能与 UX
- 对性能存在强烈分歧：
- 许多人报告在移动端/桌面端应用流畅高效，尤其是在使用 Impeller 渲染器时。
- 另一些人则描述了较高的 CPU 占用（例如 Cupertino 文本输入框、Web 演示、广告或 webviews 之类的平台视图）以及卡顿的滚动，尤其是在 iOS 和 Web 上。
- 共识是：Flutter Web 的成熟度和性能都不如原生目标；如果 Web 是主要平台，它并不理想。
替代方案与长期性担忧
- Kotlin/Compose Multiplatform 被讨论为一个正在崛起的竞争者，具备更好的原生视图互操作性，但它仍处于 alpha 阶段且较为粗糙。
- 一些人对 Google 对 Dart/Flutter 以及 Fuchsia 的长期投入表示担忧，而另一些人则认为最近的采用情况与“正在消亡”的叙事相矛盾。