Notes on Flutter & Dart
Just a brief summary of notes I collected while doing research and going through a couple Flutter and Dart tutorials, in the context of using Material Design for cross-platform development:
Absolutely fantastic Hot Reload & Hot Restart experience!
On-boarding and tool setup took about 1 hour and is also really smooth … plus another hour or so in my case to upgrade Xcode, which I hadn’t touched in a while. flutter doctor is very helpful. I was able to have a tutorial app running on both an Android and iOS device in less than 3 hours total, starting from nothing.
Very good documentation and guides. They do lack behind the frequent changes of the framework(s), but hey, I can always submit a pull request, right?
Writing a couple hours of Dart was moderately painful, though, compared to my daily use of Kotlin and TypeScript:
- Poor type inference: I factored out some of the widget tree creation into separate builder functions and did not declare the return type because to me it was clear what it was and I expected type inference in Dart to figure it out, just like it works in Kotlin and Typescript. The Dart compiler did not complain, but when running the app, the screen filled with errors about
List<dynamic>having been expected whenList<Card>was actually returned from my builder function. Explicitly declaring the return type of my builder function fixed that, but I expect to be warned about stuff like this during compilation, not during run time. That’s the whole raison d’etre of a type system. - No real anonymous functions, but just single-expression lambdas
- Semicolon and other syntactic noise
Writing UI code in Flutter/Material also seemed cumbersome–at least compared to my daily experience using HTML5/SCSS/JSX and other templating languages:
- Necessity for pixel-level control (for things like spacing/padding) is not really helpful across devices. Items laid out in a card to look good on one device did not properly fit when rendered on another. I am coming from a position where a lot of the dynamic placement of UI elements is handled via truly relative and responsive CSS.
- Resolution-dependent image selection did not work consistently for me.
- Theming is cumbersome, opaque, in frequent flux and buggy. It’s also incomplete, meaning that in edge cases widgets try to “guess” which theme property to rely on when rendering something.
- Input field decoration as proposed in Material guides prevents “tabbing” between them. This may be a documentation issue and I haven’t explored actual forms yet.
- Even though it is somewhat expected in the context of providing a consistent Material Design UX, the framework seems to be doing a lot “by hand” instead of relying on OS-specific UI features. Reading through the Flutter and Material source code reminded me a bit of the Adobe AIR/Flash/ActionScript UI code I wrote almost a decade ago.
- Despite claims, UI animations are janky even in production builds running on an iPhone 8s. In my specific case, “animation” merely meant the transition of a form field’s placeholder from the center of the field to the border upon receiving focus. That’s not an animation that should stutter.
The whole developer experience of having UI component structure and behavior so closely intertwined with appearance and theming just feels like a step backwards. So does Dart from a language design, despite it enabling Flutter’s awesome Hot Reload.
My personal take on the shortcomings above would be completely assuaged by the speed of mobile app development possible via Hot Reload, but my initial impression–pending further experimentation–is that the quality and responsiveness of the end result is subpar compared to what my team has been able to accomplish for mobile web apps just using HTML5 and CSS.
