Flutter first impressions
Tags: flutter
Published: 2018-10-20 19:18:57

---
title: Flutter first impressions
published: true
description: Android-developer opinionated review of the Flutter plaform
tags: Flutter
---

# Flutter first impressions

After hearing so much hype around the [Flutter](https://flutter.io) platform, I decided to give it a try and write about my first impressions on the developer experience. I’m an Android developer and the idea of writing the same code for Android and iOS is quite exciting.

Since I didn’t have any excuse to use Fluter on my company or a personal project, I searched for a few public APIs and decided to write the most simple app around it. I found [Tronald Dump](https://www.tronalddump.io/), an API & web archive for the dumbest things Donald Trump has ever said. *(I think the archive is not being updated anymore but that was still ok)*

Here’s the simple app I wrote:

{% youtube ul7ygXDXn3Y %}
(iOS version; Android version here https://youtu.be/aS14Eobn738)

# What I liked:

- **Documentation**: The official docs are helpful and cover most scenarios you’ll need to get started: widgets, networking, persistence, testing, etc.

- **Community**: There’s already tons of tutorials on Dart and Flutter for things the official docs don’t cover. For instance, I used the MVP architecture and dependency injection described by [Chema Rubio](https://medium.com/@develodroid) in his [blog post](https://medium.com/@develodroid/flutter-iv-mvp-architecture-e4a979d9f47e).

- **Hot reload**: As good as everyone says it is. It’s true that every now and then you need to rebuild the app, but for tweaking the UI its a great experience. I felt that it makes you learn faster, because you can quickly see what works and what does not.

- **Dart**: Coming from the Java world, it’s not difficult to get used to it. The [async/await](https://www.dartlang.org/tutorials/language/futures) reminded me of [Kotlin’s coroutines](https://kotlinlang.org/docs/reference/coroutines-overview.html) and that was nice. It provides constructs for functional programming and a [Streams API](https://www.dartlang.org/tutorials/language/streams). Or if you come from RxJava world and can’t live without it, there’s also [RxDart](https://github.com/ReactiveX/rxdart).

- **Testing**: There is out of the box support for automated testing in Flutter. I tried each type separately ([unit](https://github.com/RicardoBelchior/TronaldDump/blob/master/test/quote_test.dart), [widget](https://github.com/RicardoBelchior/TronaldDump/blob/master/test/quote_widget_test.dart), [integration](https://github.com/RicardoBelchior/TronaldDump/blob/master/test_driver/tag_screen_test.dart)) and — comparing to Android — the experience felt very natural and I didn’t find any issue, just following the official docs. Even though my test tests were simple, I felt confident it could easily scale.

# What I disliked:

- **Semicolon (;)**: Java requires a semicolon. Kotlin does not require a semicolon. Dart requires a semicolon. Javascript does not. Grrrrrrrrrrr… ([would be cool to use Kotlin with Flutter](https://discuss.kotlinlang.org/t/kotlin-language-feature-request-support-flutter/8134), although that’s not happening anytime soon)

- **Start-up time**: It’s not huge, but there is a noticeably larger start-up time than your standard hello-world on Android. I wonder how much of an impact this will be, when you have to initialise a bunch of dependencies typically required on a comercial app (crash reporting tool, network services, advertising services, analytics tools etc.)

- **Architecture**: Or lack-of architecture. Flutter can be quite flexible in the way you want to write your apps. That is great. However Flutter seems to be in a position where Android was not so long ago, in the way that there wasn’t an official recommendation on how to build an app. And that led to too many apps becoming a [big ball of mud](https://en.wikipedia.org/wiki/Big_ball_of_mud) — no separation of concerns, little testing, and difficult to maintain.

I understand that may not be a priority for the Flutter team but I’m afraid those issues can easily happen. On Android, a considerable part of the UI is written in the XML files, which forces programmers to separate (at least a little bit of) their UI and business logic. With Flutter, since everything is coded in Dart, I think we need to be a bit more careful to not violate these separation of concerns.

Another example: I found it very helpful to have a separate class file for strings, another for colours, another for routing, etc. But that was my choice. I could have been lazy and not done that. That could easily become a pain to maintain and refactor.

Also regarding architecture, there’s already several non-official patterns out there: [Stateful/Stateless Widgets, InheritedWidgets, Streams/Sinks, Redux, etc.](https://www.youtube.com/watch?v=RS36gBEp8OI) I don’t want so many choices… Which one should I pick? =)

# Wrap-up

I wrote a very simple app and there were many topics I didn’t cover, but are still important on production-ready apps: local database, tools for crash reporting, analytics, advertising, etc.

Overall I was happy with the learning experience. You can find the source code here https://github.com/RicardoBelchior/TronaldDump/

Hope you enjoyed, please leave some comments or hit me up on Twitter https://twitter.com/belchii