React Native

React Native was the obvious first candidate, I’m comfortable with the React ecosystem on the web, so leveraging it for mobile apps seemed like a good option. I found a couple of React Native slider components, but the options just didn’t seem native looking and didn’t feel native performing enough, very mixed in terms of support and a bit odd and rough.

Also I began to be aware of quite how different React Native is from writing React code for the web. While it uses the same React paradigm, there’s still a lot of differences. It seems performance is reduced significantly as your application and the react framework is controlling all the high level rendering functions from within a JavaScript control thread.

Flutter — Initial thoughts

Looking into Flutter.io I noticed from it’s FAQ, that Dart compiles to native code on both android and iOS. Sounds awesome for performance and that native feel.

Flutter doesn’t actually render your platform specific controls, instead it features a sophisticated and optimized rendering engine of it’s own and renders it’s own controls. This sounded like a strange choice to me at first, even after reading their rational of not wanting to be bound by the intrinsic specifics of the platform controls themselves.

So Flutter is actually pushing pixels itself, sounds strange, but it works —

First thing I did is download their sample app and run through the setup guide, installing the IntelliJ IDEA plugins and try to build it. I already had some Android dev tools installed and setup was a surprising breeze! Very quick and painlessly, I had their example app showcasing a catalogue of their pre-made widgets, animations and functionality.

I was seriously impressed with how easily it had just been to build the Flutter sample app and deploy it to my device + emulator. Equally impressive is the performance and completeness of the catalogue of native looking widgets and examples they already provide. Serious potential!

Still I was very dubious about the necessary time investment to learn a whole new framework (and language!), I wasn’t looking forward to it, I wanted two use what I knew, I wanted to focus only on the product not the tech stack. But the lure of a React-inspired, fast user interface development and a ready made component library was too great a lure. I decided to see what I could get done in a day, it’s Saturday after all and allowed to experiment.

Writing Flutter & Dart code

Dartlang seems very JavaScript like at first, which made it easy to chop around with and Flutter’s method of building a component tree and rendering it based on state was very React like.

I soon realised If you know React, you can hack in Flutter.

There are indeed differences as your start to delve deeper into Dart and Flutter, some even very pleasant ones.

Let’s start with the not so pleasant ones.

Component Layout

Part of Flutter’s layout system borrows much from Flexbox, so you can re-use that knowledge. While I don’t doubt it’s very powerful, I experienced it can get quite tricky to a first user. A few times the layout has has exploded on me, seemingly mostly to do with unbounded box constraints, I’m still learning it’s subtleties here.

It does have a visual helper of sorts

and the ability to dump the render tree textually to help debug these sorts of issues, but regrettably and understandably nothing quite as kick-ass as Chrome Dev tools.

Also, slightly more advanced layout with animations quickly lead me to using the Sliver classes which I don’t feel are documented well enough. It would be great if the IDE could help us a bit more here on catching rendering issues, (by checking types?) before actually rendering.

Still kudos to the Flutter team, their mix of debugging options and errors got me there in the end