Intro
We all get tired in our relationship with a programming language/platform at some point. Hence, I decided to plunge into the depths of React Native and ditch Flutter completely. Nah, bruh! Gotcha! I’m just playing with you, because I knew React Native, and had done apps with it, before I went into Flutter development.
In today’s article I would like to offer my inadvertently doubly biased (as I did work with both technologies) point of view, and ultimately “decide” on which one is “better” and why. I think we will end-up in saying that each has its place, but let’s go and see what happens.
ReactNative
This is a UI framework, backed by Facebook (impressive stuff, huh?). The tool we all know (and love, I reckon) had its first stable release on 26.03.2015. How did it come about, though? History has it, that way back when, in 2012, The Man himself (M. Zuckerberg) said that Fb had too much HTML and hence an unstable mobile performance was troubling the company, hence a new solution was needed to alleviate that problem.
Flutter
This is a UI framework, baked by Google (may the “who is boss” comparison begin!). The Alpha release (v. 0.0.6) was announced in May 2017, and the v. 1.0 (first stable version) came out on 04.12.2018. Historically, the idea behind this new way to do mobile stuff was to be able to achieve 120 FPS in rendering on Android devices and was initially known as Project “Sky”.
Something in common, much to differentiate
The common
As you may know, both of these frameworks are used to produce the so-called “hybrid mobile apps” or “apps to cover both Android and iOS in one codebase”. And that is great. I am a dedicated fan of having to touch less codebases to get the same thing done.
Also Flutter, and React Native are sharing a few more things in common. That is: by definition they are reactive and imperative.
Aha, good! But what does this mean?
No matter if you use either of these you will be tied to a state. That state will then “power” the re-rendering of the UI. As a matter of fact, both ReactNative and Flutter force rerendering when their state changes. This is why we call them reactive.
Now for the other buzz-word. Whenever you are defining the render (the return statement in a ReactNative component or the @override build in Flutter), all you really care about is the end result of the UI.
That is the same thing as to answer the question: where will the UI end-up by ignoring what its initial state was to begin with? That by definition is imperative.
But this pretty much sums what is in common between these two.
The different
It is only normal to have a lot of differences after all these are two different animals. But here are some of the most notable ones.
First and foremost Dart vs JavaScript:
Well let’s start with the elephant in the room, shall we? These two platforms use a completely different language. We all know what JS is (a home and place of constant mind games?), but Flutter uses Dart.
One fun fact about Dart is that it is backed by Google’s Ads Dept. As they still bring large chunk of the bucks home, this means Dart is not going to the Google graveyard any time soon. There also is a popular comparison between the JS superset, named Typescript and Dart. This, to me, is fair enough, as TS eliminates much of the Wild West in JS and makes life much easier. However there are some important gotchas, take Dart’s idea of constant for example (a constant in Dart must have the same value every single time the program runs, for example const Text(‘HI’)).
In JS a const is just an immutable value (e.g. you cannot reassign this later on), such as const now = new Date().
Render, render, render:
The user will not care what we programmed, unless he sees the glamorous UI and interacts with it.
And it is precisely there, where I find the biggest difference, and power, in favor of Flutter. ReactNative turns out to be the “lazy programmer” in this situation and compiles the code to native views, which are then rendered natively by Android and iOS. This is good in a way as the final result is guaranteed to appear according to the specific OS.
However it is much less flexible and efficient than what Flutter has to offer. The latter uses the 2D rendering engine called Skia. This library is also used in some obscure places, such as the browsers Chrome and Firefox, and a very non-popular mobile OS, named Android. But that is not the point. The point is that Flutter’s highly sophisticated rendering (read this insane blog about it here)will allow you to control each pixel on the screen.
Also there is a complementary structure of three widget trees, which helps the platform decide which widget needs a rebuild and which does not (for example here the const keyword plays a huge role as const widgets are never redrawn).
Go fast or go home:
The third point of difference is the performance aspect. As we all know the little choices made along the way shape performance in the end. Here is how Flutter wins this segment too. All you write in Dart and the 2D rendering library are compiled directly to an OS-readable binary. This means they are a “part” of that system as much as any native code you write. The ReactNative world here is a bit more complicated.
The core of their solution is a “lightweight” (whatever that means with output files in the vicinity of 200MB in size) VM to communicate with the native core over an asynchronous batched bridge. What this means is that the solution is not like Cordova or Ionic where the application used to run bundled a browser. Even though this approach makes the app behave like native apps (clue is in the name ReactNative), there is still a considerable risk of lowering app performance, because of that communication between the native core and the VM. However, don’t quit RN just yet. More often than not, bad performance is due to bad programming.
The learning curve
I love learning new things and it is my belief that we must never get lazy with the acquisition of know-how or fall behind on new technologies. After doing multiple apps in RN and Flutter, here is my perspective on getting to know both.
If you used to be a web dev: RN is easier, especially if you used/wrote any React; Flutter is harder, especially if you are not used to strongly typed languages as Dart will ‘yell’ at you for each and every error you make, including meticulous warning messages on bad naming and such. On the other hand Flutter uses the so-called ‘widget tree’, which looks familiar to a DOM tree. Learning curve analogy: RN = smooth; Flutter = steep;
If you used to be a mobile developer with Java/Kotlin and Objective C/Swift: RN will look too much like writing in the language you generally hide under the bed, so your friends don’t find out you secretly like it (JS). Flutter will feel unfamiliar in many senses as well, for example there is no getting a view by id to modify its text (a thing Android used to do all the time). Learning curve analogy: RN = steep; Flutter = steep;
If you used to be deep in the backends of the JS or any other language: RN will come off as a surprise trip into CSS land and what not. We assume one could manage, but the joke that backend devs are pretty bad at FE is no fluke; Flutter will be even harder, as you will need to be aware of a lot of UI management (for example the fact a column must always be constrained in height, otherwise you get an error if you put a scroll view/list in it).
Learning curve analogy: RN = moderate; Flutter = steep
But what about the trends?!?
We all love a good trend or a jolly comparison. The top10 of this vs the top 10 of that, pros and cons, lists, charts, you name it - we like it. It is in our blood. And it is only natural. After all, we are trying to make some finite decision on what to use. For this section, one can go far and wide in search of both meaning, data and sometimes even stumble upon meaningful data. But me, I am a simple man, I see Google Trends - I click it.
At first glance, the past 12 months show who is boss in trendiness. Flutter wins with an impressive 76 to 44 in popularity. If we pull further back (24 months) things look no different with 70 for Flutter to a steady 44 for ReactNative.
Looking at the Planet Earth pictogram (I mean ugh map), we can spot the hottest Flutter and ReactNative Zones. Places like China, Kazakhstan, India and Australia love Flutter. Interestingly, there are a handful of countries in love with ReactNative (or love-hate relationship - depending on how you view things). These are: Argentina, Sweden, Finland, Serbia, Belarus and Bulgaria.
Enough talk! Let’s pick one and go code already!
So at the end of the day one must make his choices. But to do so wisely there may be a lot of considerations to take into account, such as:
What does the client want?
Who can develop / maintain / test this app?
Is it a sustainable and well supported solution?
What is the ecosystem like?
Are there known issues? Are these being solved? Etc.
My 2 cents in this comparison will go to Flutter, but not necessarily because of the advantages I cited above (btw. I forgot to tell you there is web support too! Can’t wait to develop a web client with that thing.).
What attracts me most is the sense that no matter how much you develop, it is all rock-solid and well organized. Dart does not let you do any nonsense and the Flutter platform always gives you a ton of hints about what is not going so well with your application. At the end of the day it is all a matter of preference. Currently, I have 5 applications with RN and 3 applications with Flutter. Looking forward to even that score! From there on - we shall see.
Thanks very much for reading,
Petar Yonkov