re: Flutter, Ionic, React Native or Xamarin? What you use and why? VIEW POST

VIEW FULL DISCUSSION
 

Hey @moumni - I think that like most subjective questions, we need to start with the simple answer which is "It depends".

It depends on what you are trying to achieve, what your resources/budget are, and what your current background/skillset is. It also depends on whether you are looking at this from a learning perspective or from an immediate-production perspective.

That said, this is how I view it:

  1. From a maturity perspective I would argue that Ionic has been around the longest, while Flutter is relatively new, and React Native finds the middle ground. So if you are looking at legacy projects or for folks with broad expertise in the space, Ionic and React Native are both good candidates. If however you are looking at long-term futures, I can see Flutter becoming competitive. At the very least, playing with it right now will give you early insights into the platform and a bigger chance to get engaged in contributing to the development and community around it.

  2. From a support perspective (as in who's backing this) my $0.02 is that the odds favor React Native and Flutter simply because they are backed by the big guys (React Native from Facebook, and Flutter from Google) both of which have vested interests in the mobile apps and experiences market (e.g., the advertising moneymakers are mobile) and are investing time and resources in advocating for their development. While I haven't played with React Native recently, I did spent all of Google I/O attending the Flutter talks and sessions --- and when you see them treating Flutter as an equal to Android, iOS and web (e.g., in implementing Material Design widgets, supporting Firebase client libraries etc.) you tend to take that more seriously. Ionic on the other hand has a huge following amongst web developers -- but is essentially not as deep-pocketed as the other two.

  3. I recently did a lightning talk on Flutter (shameless plug I know) and had this slide which is adapted from one that is used in many Flutter talks. It might give you another frame of reference to compare the three. I have not used Ionic myself but believe it relies on Cordova to create the native mapping. So in this grid, it would in the "Interpreted and non-Reactive" square.

The Mobile UI Landscape

The point made here is that both Cordova and React Native still operate within the JS realm; in both cases, you still have JS code in a "contained" view which is run within the native environment and invokes native APIs and widgets as needed- which incurs overheads in transitioning between JS and pure native environments. By contrast Flutter does not use ANY native OEM widgets. Instead you write your apps in Dart (yes! I didn't say it was perfect) and the Flutter tooling takes care of compiling this into pure native code that is packaged and shipped in native markets; there are no "JS bridges". The way they achieve native widget parity is by literally creating and maintaining Flutter widget collections ("Cupertino" for iOS and "Material Design" for Android) that are fairly comprehensive in covering the widgets provided natively by those operating systems. So if you measure value by performance, then Flutter is a little ahead of the pack and likely to keep improving

All three options are open source. But Flutter is no silver bullet so don't assume equivalence for production. For instance:

  • It is still a Beta 3 release. They call it production ready but I know agencies and companies that don't consider it viable until it hits at least v1 and has a few more large-scale signature app deployments.
  • It requires developers to learn Dart. Granted Dart is easy to pick up if you know Java, JavaScript or Swift -- but it is still a new language and environment, with all the learning curves that entails.
  • It still has a lot of "to-dos" - check out the growing list of issues. Since it is still a small team at Google, this will take some time; the upside is that there is a hugely engaged community and the Flutter team is super responsive to ideas and contributions.

There is more to say but hopefully this gives you a starting point for the discussion. Note however that after being in this industry for over two decades, I no longer believe in "winners vs. losers" -- rather I think its important to be pragmatic and adaptable, and pick the technologies that suit your immediate needs best, even while you learn things that are on the horizon. I remain a fan of all three and their engineering teams.

 
 

I would love to use Flutter but the problem is its base of the language dart. It's great if you like/ know Java but I'm a JS guy, why Google I thought your a JS fan like me man.

 

I'm also a JavaScript developer. Trust me. Dart is really easy.

 

The Flutter team didn't chose Dart because it just likes Dart.
There are concrete reasons why Dart is a great fit for Flutter
hackernoon.com/why-flutter-uses-da...

This is all great, infact I am convinced to learn dart instead of ionic but is there a way to incorporate soket.io are some like that (packages)?

 

the problem is its base of the language dart. It's great if you like/ know Java but I'm a JS guy

Dart is also great if you like/know JavaScript. The syntax is familiar, and you can be productive in little time. I'm also another JavaScript developer who has come to appreciate Dart's offering. However, I am curious about your concerns–perhaps you could share a bit more in this discussion.

 

A friend of mine recently got into Flutter and liked it a lot, although his main concern was the lack of clear "conventions" (as he said it : "it's awesome but it's hard to find out what's the best way of doing something"), what are your thoughts on this ?

 

Yes, absolutely. I am actually going to answer this in two parts.

First, Flutter is still in beta (currently beta release 3 I believe).

I am guessing that the Flutter team is racing to complete a number of issues that need to be addressed (e.g., in terms of missing widgets or libraries, enhancing or providing key features like accessibility and internationalization, tackling performance targets etc.). And since they are a fairly small team, that means that things like documentation and best practices may not be as comprehensive as they should be.

That said, I have been seeing an incredible number of resources popping up -- from a full-set of new codelabs to a free Udacity course to a growing list of YouTube Videos and Shows from Flutter team developer advocates.

If I had to guess, I would say that developer evangelism is a huge item on their list and that we will start seeing a lot more content/guidance coming out over the months leading up to the official v1.0 release.

Second, Conventions are often the byproduct of usage, and we need more usage.

What I mean is that people who write the middleware, libraries, APIs and platforms may not always know how those get used by developers. Conventions are often driven by best practices derived from widespread usage -- and in that sense, my hope is that we will see more conventions defined later in 2018 because organic usage of Flutter is trending upwards.

My best advice for right now (and in fact, this is what I do and plan to do more of) is to sift through the open-source examples to understand how various things are being implemented, and learn by duplicating and then customizing those for your needs. The awesome-flutter repo is a wonderful source for open-source community apps as well.

That said, I will leave you with two observations.

First on coding conventions. I do think the Flutter team has done a great job with providing a built in formatter that automatically reformats code to align with specific code conventions. If you work with distributed teams, or if you share code with others, having an objective formatter is great because it results in code that looks familiar and consistent to everyone (even if your inner control-freak is incensed by their indentation count).

Second, on design conventions. I think this is what you are interested in and the challenge I foresee is that Flutter is aiming to be a universal app framework that appeals to web, Android, iOS and other mobile platform developers. And each of those domains/developers comes with some baggage on design conventions established within those domains -- that now have to either translate into this realm, or be overcome and new ones learnt to be productive. And that may be the most interesting and valuable thing that comes out of organic community contributions to this discussion -- ways in which we can unify our thinking around this new platform by bringing best practices from environments we are familiar with, while understanding the strengths & weaknesses of this one.

Hope that helped

Awesome answer, it definitely helps, I'll forward this to my friend !

 

I'm so excited about Flutter, if they do it right it's going to change the game. A lot of companies don't have budgets for two teams and they're going the React Native or Cordova route with all the limitations they have...

To me it really makes no sense to have two different teams building the same exact app twice, with a different set of bugs :D

 

Dart's learning curve is that tough!!! Dart is really easy, and beautiful

code of conduct - report abuse