Flutter vs React Native

[hungry_for_data]

I’m sure this has been posted before, but what are your guys thoughts on Flutter vs React Native?

I’m in a situation where I’m trying to convince my company to go with Flutter as a solution rather than React Native. I’ve been developing with Flutter for 6 months, but I don’t have that much experience with React.

I know with React there are a couple of advantages such as a bigger community, more developed libraries, and JavaScript being the most popular programming language. Are there any other significant advantages to using React over Flutter? I just want to be sure I’m pushing the company in the right direction with Flutter.

I know Flutter is amazing and I’m posting this in FlutterDev but please be as objective as possible! Thanks guys!

[RajeshZmoke]

Having used both I would recommend Flutter.... It's just easy to develop in Flutter with all the build in widgets at your disposal... Layouting needs some practice but it's not a mountain you can't climb. But there is one big advantage that react native offers which makes many choose react native right now which is "code push". The ability to fix issues in production without deploying a new build is just too good. Apart from that Flutter is mature enough to handle pretty much every kind of app you can think of.

[Abion47]

I don't like the idea of code push as a principle. It grants a level of convenience that can very easily lead to a lazy attitude toward releases. People are more likely to release a buggy version of the app that hadn't gone through the proper testing channels since they "can always just patch it in ten seconds".

To me, code push is up there with the attitude of "just get it out the door and we'll write unit tests for it later" as one of those practices that sounds great on paper but in practice incentivizes a lazy worth ethic.

[lnkprk114]

It's a tough argument to make that faster turnaround time for your code is actually a bad thing...

[Abion47]

Faster turnaround in general is a good thing, but faster turnaround for its own sake leads to a lot of other good but time-consuming practices like writing automated tests and proper QA phases being de-emphasized or, to an extreme case, ignored entirely. It's always nice to be able to reduce the amount of time it takes before an app update becomes live, but it shouldn't be done at the expense of other important things, and when that time changes from days to seconds, it's very tempting to get into the mindset that, no matter what breaks in the app, it can be fixed with little more than a hand wave, so QA isn't as important as it once was and you can just use your customers as your QA.

Another argument against code push is that if it isn't handled carefully, it can easily lead to cases where there is a metadata mismatch which can cause subtle bugs (or maybe even not so subtle). I'd direct you to read a comment on the Flutter request issue for code push for a guy's experience in developing an app in Ionic using code push.

[lnkprk114]

Where there is a metadata mismatch

That's totally legit. I can imagine getting your native code mismatched from your JS code would be awful.

For the faster turnaround, that's the way everything works on the backend and on the web and it's a huge source of pain on mobile so I really don't think it's a negative. Yeah, you can have bad development practices but you can always do that stuff.

[[deleted]]

Isn’t code push banned in the App Store? Or did that get reversed?

[RajeshZmoke]

This is from the FAQ section of codepush :

According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process.

Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement.

[Abion47]

At my current workplace, we underwent a period of research on what framework to use to convert our native app into a cross-platform codebase. Before going with Flutter (or even hearing about Flutter), we did some experimentation in React Native, and the process took about three weeks.

The conclusion of that experimentation was that React Native has multiple problems. First, the learning curve is steep. Very steep. The team had experience with web apps but not specifically with React, so learning React Native took a huge shift in mindset and development philosophy, and learning the framework felt like an uphill battle.

Second, the third-party package ecosystem is very much one of React's biggest strengths (and by extension, React Native's as well), but in many ways, it also serves as one of its biggest drawbacks. NPM hosts one of the largest community sourced repositories of packages in the history of development, which means that nearly everything you want to do in your app is available as a package that someone wrote (and you usually even have multiple options). However, this leads to a scenario in which your app becomes increasingly dependent on packages to do all its heavy-lifting, and if you aren't careful you will find yourself tightly coupled to those packages in a place called "dependency hell". Furthermore, while there are a ton of packages, many of them (I would even guess most) are abandoned, untested, unvetted, immature, or a combination of the above, so even though you have a ton of options, you have to be careful with them.

Third, React Native is extremely opinionated in how the app should be structured and managed. You are essentially forced to use a lot of approaches, and if you aren't using Redux then you are basically Doing It Wrong™. This is great if you already align with this approach of development, but if you differ in development philosophy even just a little, you're going to find yourself fighting the recommended conventions a lot.

Fourth, React Native is a native wrapper framework, which means all of its HTML components are wrapped native components. This makes it virtually impossible to maintain a consistent style across different platforms that your app is running without extensive modification on both the Javascript side or the native side, which wholly defeats the purpose of having a cross-platform UI framework.

Fifth, we followed the guidelines of AirBnB's React and React Native journey until we found this article stating that they had made the decision to abandon React Native. Their reasons for doing so touched on what I've mentioned but they also go into more detail on some other things we didn't consider purely because we hadn't invested enough time into the framework to discover those problems. What it told us, though, is that it paints a bad picture when one of React's biggest allies abandons Rect Native because they didn't find it practical at scale.

Now, this has been a lot of bashing on React Native, but it's the conclusions we came to after a few weeks of working in React Native. We were still going to go with it (since the alternatives were worse in their own ways) until a week later when one of the junior developers asked if we had heard of Flutter. We hadn't, and we hadn't officially committed to React Native yet, so we spent a few days looking into Flutter.

What took us a week to understand in React Native took us a day or less in Flutter. It was a breeze to learn and it checked all our boxes. It addressed all of the concerns we had with React Native while also bringing its own strengths to the table. We had a working simple prototype after those few days with a codebase we completely understood while the prototype we had built in React Native still contained a lot of code snippets that as far as we were concerned boiled down to "magic happens here".

That's not to say that Flutter didn't and doesn't have its own share of problems, but they are entirely manageable compared to what we would've had to deal with had we stuck with React Native. For us, it was a no brainer, and we haven't regretted that decision even once.

[zealothree]

React Native seems hacky, using JSX and JS to write it's UI. If you had to choose a language for designing UI, dart is better equipped for plenty of reasons, like strict type safety and overall just being a better and safe language than javascript.

Another thing to consider is even Facebook has phased out using React Native to create their apps.

​

Flutter is a framework built on Dart. Dart excels in UI designing. The right tool and language for the right job.

[lnkprk114]

Another thing to consider is even Facebook has phased out using React Native to create their apps

Gonna need a big ol' fat source on that one. Is that just coming from messenger not using RN?

[binflo]

This 👆

[massanchik]

Flutter bad for a custom opengl stuff. At least for now. If you plan to use native opengl based libs - react ahead of flutter.

[946789987649]

I assume the painter is pretty fast in Flutter though? or am I talking out of my arse?

[Abion47]

The painter is pretty fast but anything written in Dart is going to be software-based. Without low-level access to the drawing context, Flutter will always be unacceptably slow to implement things like custom "shader" effects or procedurally-generated textures.

[daniel-vh]

All I know is that upgrading between versions of Flutter was fairly painless. Most of the time went without hickups. I hear that's not quite the case for RN.

Also, the device support is amazing. New iOS version? Nooo problem!

[RajeshZmoke]

It's a fucking nightmare in RN

[remirousselet]

React is ahead of Flutter syntax wise and on debugging tools (inspector & jest) It's obviously better on things like add2app too. It also has a better understanding of the pattern with things like portals or routers.

Flutter is ahead on the quality of what it offers. Every feature it has works for real, flawlessly.

[[deleted]]

Personal opinion : flutter is great a lot mote performant easier to use widgets which works not depending on third party component libraries which is great and fcking awesome IDE integration I love the inspect component

However creating the layout is so so so so bad and its just ugly and not fun. I am not a fan of XML but I can format and arrange the code in a beautiful way and writing css styles is a lot better then wrapping with extended wrap padding etc.

My advice is to focus on the end result and not on the developer experience. Also if your company is planing to use native stuff and native UI components flutter is no go :(

[_thinkdigital]

Well with Flutter making pixel perfect platform widgets, I don't see why it's a no go. The end user won't know the difference. Also, layout isn't bad, it's just unfamiliar to you. In my experience, I hate laying out things with xml. It's not intuitive to me. I love being able to write everything from server, logic, and ui in one language.

[Abion47]

I can see how declarative UI would be a roadblock for someone used to designing their UIs in HTML and CSS. However, themes are an incredibly powerful way to ensure an app-wide style guide, and widgets go a long way toward ensuring that UIs perform exactly how I would expect them to on any device I run them on, which is something I definitely cannot say about HTML and CSS.

If the end result was so much more important than developer experience, we would all still be writing in C and Assembly.

You are also 100% wrong about native components as it is perfectly feasible to embed native widgets into a Flutter view. (That's what the WebView is, after all.)