How Flutter led me to React Native — and vice-versa
The experience of small teams with both tools and the decisions we made aiming for better user experience in 2017 and 2020.
I had just started college in early 2017, and I was excited to join some university research projects. Most of the open positions for these opportunities demanded knowledge in the mobile development field, especially for Android and iOS, and I wanted to learn how to develop for these platforms.
The only experience that I had in the field was a really small application I had developed using Android Studio templates. I was unable to develop for iOS because I didn’t own any Apple product. That is: I didn’t have any experience at all at developing apps.
I was motivated by the scholarship these research projects offered (there is no free lunch) and by the necessity to learn technologies for developing applications to a growing audience, and because of that, I started looking for alternatives that supplied these project’s main demands.
What I’ve looked (and found) in 2017
I needed tools that were easy to learn, fun, productive. Besides that, this tool needed to offer me the ability to develop applications for both Android and iOS. Due to that, I focused my research on cross-platform solutions.
I was already an enthusiast of new technologies Google was developing. The Polymer Project is an excellent example of how, at the time, the company intended to provide a new alternative for developing Web applications. Despite that, my experience with Polymer was frustrating, and the code was tough to understand. And that’s precisely the opposite of what I’ve found in Flutter.
Try out Flutter
If you don’t know what the framework is yet or haven’t used it, you should consider that option. Flutter is a framework that provides the ability to use the dart language to develop applications to several platforms, including Android and iOS, using the same code base. Flutter uses Skia, a 2D graphic engine that, in short, lays out a canvas to be drawn by the user. The framework is built under this structure and offers total control of the pixels that are shown on screen.
Many of the features that make Flutter a productive and robust tool today did not exist when I first discovered it. In mid-2017, the framework was at its alpha release, and minimal map support, for example. Still, I decided to try it and use it a little, and my experience was terrific.
For the first time, I felt in control of what was being shown to the user. The way all the Widgets (components) interacted with themselves and what the application was doing. It was also my first experience with UI state management, and the little I suffered to understand how that worked helped me to deal with the technologies I was going to work.
I had that experience while developing an app for consulting the timetable of the local buses offered by the college I study. Although it wasn’t publicly released, the app helped me on my path to React Native (even if it wasn’t the best app design I had developed).
How Flutter showed that React Native was a viable option
I used this app to show, during an interview, that cross-platform solutions were, in fact, possible. And that was the problem with Flutter at that time: building solutions using the framework was possible, but not viable. Flutter’s team did not recommend its use in production due to the constant code evolution and the considerable amount of bugs it still had.
Despite all that, Flutter showed the interviewers that cross-platform solutions speed up the development process and help to mitigate the fact that they had a small team that didn’t have much experience, and that was continually changing. Not only to them, but it also showed to me that I was capable of developing mobile applications.
What Flutter did not show was the stability needed to develop an application in an environment in which developers would not be able to handle difficult bugs due to not having the knowledge, expertise, and time (half-time job) demanded to develop solutions that would solve these problems. Another significant factor considered was the lack of extensive map support, as the application that was going to be developed heavily relied on several aspects of geolocation and navigation.
And that’s where React Native comes in
We didn’t have to give up a lot for having the stability and extensive support to maps we needed: React Native already was, at that time, an extremely powerful tool that allowed it’s users to build cross-platform applications using javascript, a language known by basically everyone in the programming world. Besides that, the syntax used to build user interfaces in React, jsx, is very similar to HTML, which sped up my learning curve.
It didn’t offer control at the same intensity as Flutter, but it perfectly met our needs during the project execution. It was possible to develop custom interfaces and meet the needs of our users on both platforms. Yes, we did face some troubles dealing with native modules, but we were able to go through it with ease.
Those responsible for the project soon realized multiple advantages in adopting a cross-platform solution in a small environment, where small bugs can build up to high costs, and all the following applications were developed using React native. Every single person of the team that used the framework was impressed by its similarity with the Web and its performance. React Native is loved and used to this today in Smart Metropolis.
Fast-forward to 2020
Fast-forward to 2020, having developed two apps with React Native, one being MeuMenu, a food delivery app, I was now faced with another challenge: in a new research project, we should choose between React Native and Flutter to develop the project’s solutions. See, it wasn’t easy: React Native grew on me in these two years that I’ve worked with it, and at the same time, I had such an enjoyable experience with Flutter.
By having worked a considerable amount of time with React Native, I already knew what made of it a good and a not-so-good framework. Dealing with animations and native modules could be a nightmare. Although there are a lot of great UI libraries, many times, the components they offer are not visually faithful to the native ones, and I knew where I could find all this. So, I revisited Flutter.
Why Flutter in 2020
Flutter evolved in many aspects since the first time I used it. The extensive documentation, video lessons made by its developers, more significant engagement of the community in developing libraries for it: all of that made Flutter way more attractive than it once was. Besides that, during this time, several stable releases were available, and they’ve added map support 🎉.
I was assigned to the task of creating a prototype to validate the technologies we would use in the new project. By revisiting Flutter, the framework showed itself even better than what I remembered it was. The way user interfaces are declared in Flutter could not be more different than the one in React Native, but after a couple of hours of using it, building the prototype UI felt quite natural.
I was able to develop the home screen of the app in less than three days, and I even added animations to it! All of that without compromising the fidelity of the native components of each platform, something that would take more time to do in React Native, for sure. The connection to a GraphQL API was also made without any pain, and I only need to install a few external libraries to make it all happen.
After all, that was the main advantage we saw in Flutter: to us, a small team that cannot deal with huge costs created by bugs in the framework and its libraries, the support Google provides to the tool is a big factor. It means that we can take more time worrying about the user experience and less with inconsistencies of UI libraries offered by third-parties.
RN vs. Flutter? Not quite
4 out of 6 developers in our team had used React Native before, and after an analysis of both prototypes and the experiences we had developing them, we still decided to go with Flutter. Although we are a small team, it says a lot about both frameworks. The world is full of small teams that have to make the same decisions we had to make, and it directly impacts the adoption rate of the tools and which are the future priorities of each one.
Don’t get me wrong: React Native still is a viable option and a quite interesting one. Both frameworks evolved a lot in the past few years, and the addition of hooks is a proof of how React’s community as a whole rapidly reacts (insert bad joke here) to changes that are good to the users. Meanwhile, Flutter’s community still did not settle for a preferred state management strategy, and I plan to talk more about that in the future.
I genuinely believe that both frameworks will mutually benefit from the existence of one another, and I hope developers are ready to acknowledge the strengths of each framework. I’m pretty happy with the choice we’ve made, and I would be equally happy if we had taken the other option. I’ll keep posting Flutter content about my experience with it and the tools we can use to improve the development process 💻🔜.
This article was originally published in Portuguese. You can access it here.
