Wat we ermee bouwen
Dart is waar ons Flutter-werk werkelijk in geschreven staat, dus de meeste van onze engineeringstandaarden leven op dit niveau en niet op dat van het framework: hoe state wordt gemodelleerd, hoe fouten worden weergegeven, waar de grenzen tussen synchroon en asynchroon liggen.
Sound null safety is de eigenschap die in de praktijk het meeste veranderde. Een hele klasse productiecrashes — de null-dereferentie die alleen optreedt bij een traag netwerk of een leeg account — is niet langer op te schrijven. Sealed classes en pattern matching dekken de rest: resultaten die óf een waarde óf een fout dragen, uitputtend afgehandeld, in plaats van excepties die door lagen heen worden gegooid.
Waar we het hebben ingezet
In elke app in ons portfolio, plus in beide Flutter-pakketten die we hebben gepubliceerd. Ons pakket number_editing_controller is een goed voorbeeld van werk op Dart-niveau in plaats van UI-werk — taalbewuste getalopmaak met opties die tijdens het draaien te wijzigen zijn, waar het model het lastige deel is en niet de widget.
Wanneer we het aanraden
Dart is meestal geen losstaand besluit — je kiest Flutter en Dart komt erbij. Waar het wél een besluit wordt, is op de server: Dart compileert naar native binaries en kan een Flutter-client bedienen met gedeelde modelcode.
Dat raden we doorgaans niet aan. Voor backendwerk grijpen we naar Go, Python of Rust, waar het bibliotheekecosysteem en het beheerverhaal veel steviger staan. Gedeelde modellen leveren minder op dan het lijkt, en een Dart-backend verkleint de vijver aan engineers die hem kan onderhouden.
