Qué construimos con él
Dart es aquello en lo que está realmente escrito nuestro trabajo con Flutter, así que la mayoría de nuestros estándares de ingeniería viven a este nivel y no al del framework: cómo se modela el estado, cómo se representan los errores, dónde se trazan las fronteras asíncronas.
El null safety robusto es la funcionalidad que más cambió las cosas en la práctica. Toda una clase de crash en producción —la desreferencia de null que solo ocurre con una red lenta o una cuenta vacía— deja de poder escribirse. Las clases selladas y el pattern matching cubren el resto: resultados que llevan o bien un valor o bien un fallo, tratados de forma exhaustiva, en lugar de excepciones lanzadas entre capas.
Dónde lo hemos usado
En todas las apps de nuestro portfolio, además de en nuestros dos paquetes Flutter publicados. Nuestro paquete number_editing_controller es un buen ejemplo de trabajo a nivel de Dart y no de UI: formato de números según el idioma con opciones mutables en tiempo de ejecución, donde lo difícil es el modelo y no el widget.
Cuándo lo recomendamos
Dart no suele ser una decisión independiente: eliges Flutter y Dart viene con él. Donde sí se convierte en decisión es en el servidor: Dart compila a binarios nativos y puede sostener a un cliente Flutter con código de modelo compartido.
Por lo general no lo recomendamos. Para el trabajo de backend recurrimos a Go, Python o Rust, donde el ecosistema de librerías y la historia operativa están mucho más asentados. Los modelos compartidos son una ganancia menor de lo que parecen, y un backend en Dart reduce el número de ingenieros que pueden mantenerlo.
