Yes that’s right @nxsliu , I’ve been developing with React Native since it was released by Facebook in 2015!
I think there are several factors contributing to the rise of Flutter!
In contrast, Flutter uses a type safe language (Dart) which was purpose-built by Google for optimal UI development. Dart native features JIT (just in time) compilation which greatly speeds up a developers workflow. With React Native, the JS bundle must be loaded into memory and parsed before it can be executed, but with Dart, the AOT (ahead-of-time) compiler allows apps to start instantly and run smoothly.
I think that React Native developers are frustrated with some of the limitations of this environment and are more willing nowadays to look outside of the JS bubble to other solutions that exist for cross-platform client development. A natural alternative is Flutter.
There haven’t really been any major hurdles to be honest!
This was hardly a hurdle, but there was a natural learning period of a couple of weeks in which I was picking up Dart (which actually felt quite natural coming from JS), and Flutter (conceptual differences between Flutter “widgets” and React Native “components”). This was an overall positive experience, especially with some moments of delight as I realised how quickly some problems could be solved using Flutter which were previously arduous tasks in React Native. Google releases “widget of the week” videos on YouTube showcasing some of these capabilities if you’re interested in seeing some specific examples.
I think the biggest pain points so far have been related to Flutter’s fresher (but growing!) community. I am used to being able to reach out and immediately find a popular, well maintained third-party JS library when creating React Native applications. Given that developers are only more recently starting to solve similar problems in Dart and Flutter, there is less choice out there at the moment for quick-wins from that third-party library perspective. This will be the case less and less as Flutter “grows up”.
Similarly, there is less consensus about the “correct” way to architect a robust, scalable Flutter application. We are seeing developers use architecture patterns and state management solutions that they prefer and that work well on other platforms but the jury is still out on which of these approaches works best. Again, this due to the fact that Flutter is newer and people have had less opportunity to really put some of these approaches to the test in production and make their cases to the community. Often the dust never really settles with these debates either - approaches can vary widely in style and we see cycles of popularity in approach not dissimilar to those seen in the fashion industry.
Ultimately, Flutter is a framework that uses a rendering engine called Skia under the hood to graphically paint everything onto the screen, pixel by pixel. This comes with many benefits, for example confidence that an interface is going to look consistent across the platforms on which it is run and the flexibility to create anything on-screen.
The biggest downside to Flutter’s approach is, in my opinion, that it does not (and cannot) automatically keep up with updates to the underlying framework. For example, if Apple releases a new style of button for its iOS operating system, that same button needs to be replicated as a Flutter widget (either by the Google team, a third-party developer, or ourselves) before it can be utilised in a Flutter application. This leads to a delay in which new platform features can be taken advantage of by users, and can sometimes deliver a sub-optimal experience when compared to the native equivalent.
Due to this, native approaches will always have a slight advantage over Flutter in terms of delivering (what the platform thinks) is a first-class experience. When the realistic net value of this advantage is weighed against all the other benefits that Flutter brings to the table, I still think it’s the obvious choice for small to medium sized teams who want to deliver quality apps, fast.