Dart/Flutter agora tem macros/metaprogramação
Dart está introduzindo um sistema experimental de macros e metaprogramação, semelhante aos processadores de anotação do Java, com o objetivo de substituir grande parte da geração de código pesada em boilerplate atualmente comum em projetos Flutter e Dart no lado do servidor. Os participantes avaliam os possíveis ganhos em desempenho e experiência do desenvolvedor contra preocupações conhecidas sobre a complexidade das macros, o aumento do tempo de compilação e a manutenção. A conversa se amplia para a posição do Dart no ecossistema de linguagens — seus pontos fortes em ferramentas, tipagem e UI multiplataforma baseada em Flutter, em contraste com fraquezas em bibliotecas fora do Flutter, no desempenho do Flutter (especialmente na web e com platform views embutidas) e na incerteza sobre o compromisso de longo prazo do Google em comparação com alternativas como Kotlin/Compose e TypeScript.
Recurso de macros e status
- O repositório vinculado é uma demonstração; a especificação autoritativa está no repositório da linguagem Dart.
- As macros ainda são experimentais/em alpha, não GA, mas já estão na branch master do SDK.
- Elas são em tempo de compilação, mais próximas dos processadores de anotação do Java do que de reflexão em tempo de execução.
- A intenção é substituir grande parte da geração de código atual e integrar melhor com o compilador/AST.
Geração de código, reflexão e ferramentas
- Os fluxos de trabalho atuais de Dart/Flutter dependem fortemente de codegen (
.g.dart,build_runner), que alguns consideram complicado e fácil de ficar desatualizado em CI. - As macros devem rodar em memória antes da compilação e evitar arquivos gerados versionados, potencialmente melhorando desempenho e experiência do desenvolvedor.
- Preocupações com macros em geral: risco de código difícil de ler e muito macro, tempos de compilação maiores e “duas linguagens”.
- Contra-argumento: macros de Dart são escritas em Dart normal; não existe uma linguagem de macros separada.
O papel da linguagem Dart
- É elogiada por compilação instantânea, tipagem estática forte, null safety e ferramentas.
- Comparada a alternativas:
- vs Rust/Go: Dart tem GC e exceções.
- vs JavaScript/TypeScript: Dart é tipada estaticamente, sem as peculiaridades legadas do JS.
- Muitos veem o principal valor do Dart como sua integração estreita com Flutter, embora alguns o usem em full-stack e para servidores.
Ecossistema, web e recursos futuros
- A visão comum é que o ecossistema é rico o suficiente para muitas necessidades, mas ainda mais fraco que JS, Python ou linguagens JVM, especialmente fora do Flutter.
- Alguns querem Dart como uma alternativa séria ao TypeScript para apps web; outros duvidam que ele supere a expressividade de tipos do TS.
- Novas APIs da web e suporte a Wasm, além de uma proposta de multithreading com memória compartilhada, são mencionados como direções promissoras.
Desempenho e UX do Flutter
- Há forte discordância sobre desempenho:
- Muitos relatam apps suaves e eficientes em mobile/desktop (especialmente com o renderer Impeller).
- Outros descrevem alto uso de CPU (por exemplo, campos de texto Cupertino, demos web, views de plataforma como anúncios ou webviews) e rolagem travada, especialmente no iOS e na web.
- Há consenso de que o Flutter web é menos maduro e menos performático do que os alvos nativos; não é ideal se a web for a plataforma principal.
Alternativas e preocupações de longevidade
- Kotlin/Compose Multiplatform é discutido como um concorrente em ascensão, com melhor interoperabilidade com views nativas, mas ainda em alpha e áspero.
- Vários expressam preocupação com o compromisso de longo prazo do Google com Dart/Flutter e com Fuchsia, enquanto outros argumentam que a adoção recente contradiz a narrativa de que está “morrendo”.