Monday, May 7, 2018

Diving into Flutter

This March, Flutter stirred up a buzz in mobile circles when Google announced its public beta. With my background in developing Android and React Native apps, I figured I should try my hand at Flutter and see how it stacked up.

Flutter embodies the state management and component oriented architecture of React. Compared to Android's architecture, this represents a shift in how Google thinks about mobile application architecture. Flutter is an SDK which provides a component library and framework for building UIs. A developer uses the SDK to write Dart code which compiles down to native iOS and Android code. Flutter is meant to be the primary way to develop apps for Google's upcoming OS, Fuschia.

My Experience

Using the official setup tutorial (linked below), was straightforward. My first thought as I started coding was, "This seems a lot like React Native!". In both languages you write your UI definition and logic within the same file. Unlike native Android or iOS projects, you no longer have standalone UI files. The biggest benefit is that your UI event handlers are bound in the same place where they are defined, making the logic much easier to grok. In addition there are many similarities in state and re-rendering. Both libraries draw a distinction between passed in data (props/configurations) and internal data (state). Components will redraw their UI whenever this data is changed. However, Flutter draws a strong distinction between stateful and stateless components, I think the description from the docs does a good job explaining the difference; for more information look here.

“Stateless widgets are immutable, meaning that their properties can’t change—all values are final.
Stateful widgets maintain state that might change during the lifetime of the widget. Implementing a stateful widget requires at least two classes: 1) a StatefulWidget class that creates an instance of 2) a State class. The StatefulWidget class is, itself, immutable, but the State class persists over the lifetime of the widget.”

When it came to the language, I had never used Dart before, but it looked and felt a lot like Kotlin, Swift and Typescript. There is a brief sample below written in both Kotlin and Dart, I may write a deep-dive on the subject in the future if people are interested.

Some sample code in Dart

The same code in Kotlin
I prefer the syntax of Kotlin, it seems more concise and lends itself to fewer errors (an emphasis on immutability, and fewer redundant constructs). However, Kotlin can't fill the space of iOS and Android cross platform development until native compilation is supported.

In contrast to React Native, it seems that Flutter offers a larger set of components with a smaller set of options for customization. Styling with Flutter is not manged by one style prop like in React Native, instead you may end up using "style", "decoration", "width" or "height" based on the changes you want to make. This will require a bit of back and forth with the docs as you find the correct component for your complex UIs, but that is nothing new coming from the world of native mobile development.

Similar to React Native, Flutter has hot reload. this makes iterative development a breeze compared to native development, with your changes appearing immediately in your emulator as you save your code.

flutter hot reload
Just save, and your code reloads
Libraries for dart are published here, you can filter for both Web and Flutter libraries. Adding them to your Flutter project is as easy as adding a line to your pubspec.yaml and running "flutter packages get" from the command line. Currently there are about 2,100 packages available.

In the case that you want to use native logic which is not provided in the SDK or an existing package, you can write a platform channel. Platform channels are written in the native code for each platform and are analogous to React Native Modules.

Concluding Thoughts

Ranking Flutter and React Native is highly dependent on your needs. Both technologies embody the same development patterns and principles with their component focused architecture. Both seem to have fairly good support for native features and offer similar backdoors for accessing native specific logic in the form of native modules and platform channels. In addition, React Native has a large developer community while Flutter's is expanding and buoyed by Google.

Flutter can be faster than React Native or other JS frameworks since it provides components that communicate directly through native apis instead of going through a JS bridge. That said, Flutter can alienate web developers who love React Native due to its similarity to web development. Another group that would find React Native more attractive are organizations that want to share their web JavaScript logic with their mobile apps.

Flutter is write once, run anywhere while React Native is learn once, write anywhere. That said, I rarely ever build separate Android and iOS implementations unless I want platform specific behavior. Based on the large number of components and smaller set of styles, my opinion is that Flutter wants to offer a more opinionated (material) design for applications.

Flutter is another strong contender for the cross-platform mobile development space. It seems  targeted to mobile devs who want to build and maintain Android and iOS apps with more ease. Moreover, it benefits from a locked in purpose, as the development framework for Fuschia. Though it is unlikely to consolidate the fragmented mobile development landscape, it seems that Flutter is here to stay.

Want to Learn more?

I'd recommend the resources listed below to try some hands on Flutter development. The content will take you about 2 hours and leave you with a simple app that displays a list of items which you can favorite. If you are hooked, then Google is releasing a free Udacity course that you can use to continue learning.


Post a Comment