Flutter: First Impression

For the past few months, I’ve been looking into Google’s latest endeavor, Flutter. I have spent the last 3 years working on and off with React Native and have developed a complicated relationship with it. While it appears to be the best cross platform framework on the market currently, it has always come off a little chaotic and limited to me. Flutter promises a future where one code base can be used across all platforms and built using reusable widgets in a fraction of the time currently spent developing for web, desktop and mobile. All of this while offering detailed documentation and use cases for basically everything you could hope to do with their framework. So far I’ve only spent a few hours looking into the framework but its future looks promising and more importantly well documented. Below you’ll find my first impressions of the framework and a comparison to React/React Native.

When I first took a look at a sample Flutter app’s codebase, I was lost and confused. Where was the css styling? Where are the 90 import statements on every page and the 20 different libraries needed for the app to function? And why are all these constructors wrapped around each other? To me, Flutter’s layout was something I hadn’t really seen before. Basically, every single thing is a widget composed of widgets composed of widgets. That’s mostly an exaggeration but you get my point. Even the styling applied to other widgets is done by setting those widgets as children of a parent widget applying styling!! For example, you want to set the position of a FlatButton?

Wrap it in the Positioned widget under the child property then set the top, bottom, left or right properties to change position. Anything that is a child of that widget will now have those stylings applied. Just like how everything that is a child of FlatButton will act as a button.

But notice how I said the child property not children. To get multiple widgets to be a child of something you need to use widgets such as Column, Container and Stack that have a “children” property which takes an array of Widgets to display.

Now all of those buttons will inherit the stylings applied by the Positioned widget as well as the ListView.

This layout is similar to how you would structure it in React Native only using properties instead of css. The difference with flutter is the built in Material UI widgets having properties to handle specific styling such as a leading icon in the button title. Below is the code to produce something similar in React Native.

In a simple case like this the two frameworks appear very similar in layout the only difference being the use of components and css vs only widgets and properties.

This may all seem confusing but once you get the hang of it you realize the benefits of a system like this. Modularity. You can pull any widget from anywhere and throw it into your column or stack and all the stylings, positioning and functionality applied to the stack will take effect almost as if it was magic. In the words of Bethesda “It just works.” Moving components around like this in React and React Native won’t always work as cleanly due to conflicts in CSS styling that can cause major headaches for those less experienced or those using components from other libraries that make it near impossible to change certain css styles.

Another major benefit of Flutter is all the built in libraries that come standard with every Flutter app. For example, a material UI library containing all the widgets you need to build a good looking industry standard that will always be compatible with the latest version of Flutter. React Native on the other hand requires the use of third party material UI libraries that may or may not be updated on time with each new release and aren’t guaranteed to be compatible with the other libraries you need just to get a React Native app running. Which brings us to another area in which Flutter shines…building and testing apps. In React Native, we use Expo to setup an easy environment where we can run our app on various simulators and devices for testing and later deployment to the app stores. This has frustrated me at times in the past, mostly due to the web of dependencies we end up with towards the end of a project which usually look like this: We need some functionality in the latest release of React Native but Expo doesn’t support it yet due to various bugs they’ve encountered with their integration. Now we have to either stop using Expo and make the deployment and testing process 10x harder, wait an undetermined amount of time, or find a “hacky” workaround that might lower performance. Meanwhile in a Flutter app, everything you need to test and deploy comes standard and actually works. Your apps will actually hot reload or display meaningful error messages utilizing Flutter and Dart’s IDE plugins to give you a detailed analysis of what went wrong.

However, like I said in the beginning, I have only had an introduction into Flutter. I haven’t yet worked with it long enough to find all of its little annoyances like I have with React/React Native and currently despite the issues, React/React Native is still king for cross platform development due to its established presence and familiar programming. I think as long as Google and the developers working on it stick to its development, Flutter may be poised to overtake React in the future when cross platform web is fully realized and more people start adopting the framework. In the meantime, I’ll continue to research and follow the development in hopes of one day having the cross platform solution we’ve all been waiting for.