Trying out Flutter

Flutter, Google’s Dart based SDK for building native mobile applications, has been around for a while and I finally decided to take it for a spin. I’ve attempted at mobile app development before in Android but never got past Android Studio’s terrible slowness. Maybe it’s because my computer is kinda old. But that doesn’t change how bad the experience was. Also, I just couldn’t get Java through my head. It was more than a bit overwhelming to try and learn.

On the other hand, Flutter treats the command-line as a first class citizen. Tools for downloading packages, debugging, live reloading (hell yeah!) and building your app are all available through the command-line. No need of any heavy, slow IDEs (though IDE integration is definitely present). I can just do it in Emacs (although that does require some setup to get that IDE like experience. Don’t ask me how, I didn’t even use autocomplete while playing around with this. Masochism, you say? I don’t know what you mean).

Flutter has some reactive elements going for it. From the developer’s perspective, if some action causes a state change, you can trigger a rebuild of the app by calling setState. A rebuild goes back to the top of the app and cascades down the tree (the whole app is structured like a tree, with a root, branches and leaves), applying the changes wherever needed. But it’s not like a browser refresh which resets everything. Flutter is designed so that from the user perspective, they still continue to use the app as they were and they only see the changes which have been affected. This method allows the developer to easily reason about the app and its behaviour because there is only one way the app applies changes to itself. Everything flows in one direction and is easy to understand.

I should expand on the whole “the app is a tree” thing. Your UI is composed of Widgets. Every UI element is a Widget. You have a root Widget and its children are Widgets that make up the rest of the app. What about navigating to new screens? Flutter uses something called Navigator to handle transitioning between different screens. Screens in Flutter are called Routes and Navigator manages a stack of these Routes. The top of this stack represents the current screen. Moving to a new screen involves pushing the corresponding Route of the new screen to the top of the stack. Closing the current screen pops the stack and reopens the previous screen.

That’s really everything I wanted to say about Flutter and my experiences with it. Very surface level, I know. I just wanted an excuse to talk about it’s command-line interface and the live reloading (have I mentioned the live reloading yet?) and I wanted to write something bigger than the length of the tweet, so here we are.

All in all, I think trying Flutter out ended up being a good experience. I wrote a To Do app (which is what I guess most people end up making at the start). I think the developer experience where everything is command-line driven (especially live reloading. I’ll never not love Flutter’s live reloading) and doesn’t require a heavy IDE is especially suited for me, which is the main reason I like it as much as I do. Dart is pretty easy to pick up if you’re already familiar with Java. It definitely feels like a leaner Java (then again, I’ve barely worked with Java so who am I to say). If ever I need to hack a mobile app together, I think I’ll be turning to Flutter provided I haven’t found something better.