Interesting this is on the front page, yet no comments. I'm very curious as to others thoughts. We are about to start a new react native app and are considering flutter. It will be webrtc based also. Extensive experienced design team, but no dart experience. Any thoughts?
CodePush was the main reason why our team went with React Native instead of Flutter. Being able to push bug fixes to all of our users in real time is incredible.
Imo the only serious contenders for crossplatform apps are react native and flutter. There is no good reason to use other frameworks when you get similar dev speed, better community support, and a relatively fast product with these 2.
Probably 6 months ago flutter wouldn't be on this list but Google has surprisingly shown strong support
Yeah but it was really unclear for a while if Google was actually serious about Flutter. I believe they previously had a similar project which got shelved. Being the official framework for Fuschia didn't help either because at the time (and even now...) Fuschia was very very alpha so that too could be shutdown at any moment.
Google rarely keep products like this going for very long.
There are a couple of notable exceptions but the list of abandoned developer tools coming out of Google is far longer.
Given you're doubling down you're taking a massive risk as a business. As an employee you also risk making yourself unemployable going all in on Dart and Flutter.
True if you're a c# shop Xamarin might actually be a better choice. I just haven't seen many good apps come out of the Xamarin community and I'm implicitly biased because they don't support developing on Linux
I prefer not to think of myself as an X-language programmer. And yes, when I was developing mobile apps, I did it solo. I preferred to choose the right tool for the job, and learn a new language if needed.
And I think Xamarin is better than React Native or Flutter, because Xamarin makes it easy to use each platform's full set of native widgets in the native way, while still sharing non-UI code. In contrast, React Native does use a subset of native widgets, but doesn't give you access to the full set of them (at least out of the box), kind of like the old Java AWT. And like Swing or JavaFX, Flutter throws out the native widgets entirely.
We’re a C# shop, with a heavy tie into Microsoft infrastructure and Azure. Doesn’t mean we won’t be looking into flutter.
Xamarin is terrible to work with, and if AngularDart shares code with Flutter then it might be interesting to replace angularJS + Xamarin with dart.
I only clicked this article because I a Danish municipality programmer, I follow, comment on flutter, on one of the Microsoft news portals though, so the community is definitely a lot smaller than the Xamarin.
Dart is a simple language to understand especially if you come from a Java/Scala/Swift background. It’s also quite elegant with decent streams and asynchronous support.
The problem with React Native is that the complexity is higher, routing/navigation a mess on iOS and the dev experience is nowhere near as fast or polished as Flutter’s.
My strong suggestion is to invest a week with your team to learn React Native and then spend a week with Flutter. A week is enough to pick them up.
Flutter is good, I echo the author's sentiments. I wrote a Flutter app for Android in a very short period, relative to my Android Java attempt.
The use of widgets saves a lot of time, leaving one to focus on connecting everything together. It's also easier to learn than React Native (for me at least).
The current downside for me has been the lack of maps (I'm aware of current efforts). I also hit a weird Firebase Messaging bug that leads to an infinite loop of the app opening itself [0].
I agree with the author regarding the strong Firebase push. The community doesn't yet seem large enough, so outside of wine of the Google supported plugins, it's sometimes a struggle.
I am building a second app in Flutter, using the new Material stuff that Google announced this year.
For me, as a long-time Dart user, the emphasis on Firebase for Flutter surprised me at first, given that there are several existing server-side frameworks in Dart that could be used to create full-stack apps. I personally found myself frustrated at the difficulties and breakages that sometimes come with upgrading native plugins between versions of Flutter, so for some time I was confused.
But it actually makes sense on a closer look. Dart on the server is not officially supported, as the primary focus of Dart is use as a client-side language, so it would be a bit confusing for the Flutter documentation to recommend using Dart for a backend.
That being said, I think Flutter is a great platform for quickly building apps, and getting consistent behavior across different vendors. I think that it can only continue to get better.
The focus of Dart 2 and beyond is the client side [0].
You can definitely run Dart in the VM, but beyond the HttpServer API, server-side support is mostly a community effort.
My point isn't that this is a bad thing, it's that it makes sense for Firebase to be promoted because Dart doesn't have _official_ server-side support.
I just think saying that it doesn't have "server-side support" is misleading. It makes it sound as though you'd need third-party code to run on the server at all.
I do agree they have pivoted to a more client-sided branding though.
It is more nuanced: Dart on the server side is supported, but the development focus is on the client-side stories (Flutter and Angular).
Google's Dart team develops e.g. the Dart VM which is great for server workloads too, they do provide some server-side libraries, but they themselves don't work on third-party database drivers (for now).
Think of it as the question of focus: they want to focus on the client-side story, get it right, and then deal with the rest. Spreading thin won't help either.
I'm extremely surprised to hear that dart server doesn't have any database driver. Are you sure about that ?
To me , dart on the server , with their agent / isolate based concurrency as well as async await language support, provides ( in theory ) one of the most exciting environment to develop backends on.
Dart has database drivers, and I'm using the Appengine and the Postgres one in server-side Dart apps.
But Google's Dart team is not actively involved in developing e.g. the Postgres driver, it is done by an independent company who is building their stack on server-side Dart.
Btw. I agree: the isolate-based concurrency + language tools is really great for server-side Dart apps. I use it in a highly concurrent data setup, and I wouldn't switch to other language.
I assume that you're referring to the fact that you cannot create iOS builds from Linux. Otherwise the toolchain works just as well on Linux as it does on Mac.
I really want to get into mobile development, but I have major obstacles with default platform APIs: I don't have a Mac (and cannot afford one ATM), the Android Studio is unusably heavy for my decent laptop, and writing Android apps w/o the studio seems prohibitively difficult. In this situation, Flutter is a liberating force for me. I have recently started learning it, and I can just keep writing my code in Emacs, while running the app on a phone with hot reload, and without my laptop melting. Thanks to whomever created it.
A lot of the core contributors were members of the original Chrome team; Hixie's far from the only Flutter contributor who previously worked on the web for 15+ years.
Why do you say writing Android apps without Android Studio is prohibitively difficult? I did it. You just use Gradle from the command line to build the app, and adb to install it on your device to test. I only tested with an emulator when I didn't have a device.
Some web pages I read make it look like so, and not only, some say directly that it's impractical. But maybe it's my infamiliarity with the ecosystem that makes me think so. If you know of a nice tutorial I'd really appreciate it!
You forgot to mention the slow build times when using Gradle. If Android Studio is too heavy for his laptop then Gradle's hardly going to be much lighter.
Unfortunately, even Flutter requires it when building the production-ready Android version of the app. Perhaps it's time Google switched to their own Bazel as the default for building Android apps. As a bonus, the syntax is a lot lighter than Apache Groovy's.
My CPU is "Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz" par lscpu(1), and I have 4Gb RAM. I should not have to struggle running end-user desktop software except inherently-heavy tasks like video editing and similar memory-heavy or very CPU-intensive stuff. And running a text editor, a compiler and a debugger is definitely not so. I'll go as far as saying that most desktop software that I can't run easily is just plain bloatware. Android Studio, definitely checks out.
I don't know Gradle, I'll try when I have free time. I have one project which can be better off as a Java API app (based mostly on Intents). WRT Flutter, I have not experienced any performance problems with it so far; though I haven't built a "production-ready app" yet. But given it'd mostly be a rare task, that'd be bearable.
Hey gkya, I'm the author of the post. I basically have been a long time Mac user and now I have a window machine with a VM with Xubuntu where I do all my dev (I only game on windows). When I want to test cross platform I use my wife's Macbook pro. When I develop and maybe don't have enough RAM to use an Android Emulator, I've found running the app on a real device works well actually.
Hi, thanks for writing this article, it was a nice read!
WRT Macs, well, I use a Unixy laptop since time immemorial, one way or another (stuff I spent >1yr with: Ubuntu, Arch, FreeBSD, Xubuntu, and finally and currently Debian; in that order), and being quite content with what I have at hand, I'd be reluctant to switch anyways. But AFAIK the App Store is where the money is, so I want to get in to it ASAP.
I'm in a rare situation where I'm a long time amateur/semi-professional programmer, but I study and plan an academical career in humanities. I need to write up a couple apps to help interacting with documents (what's available on mobile is basically sub-par), so I'll code them up anyways, but I'd be glad if I could share them FOSS but also get some amount of money from the app stores. Even a hundred or two hundred dollars a month would help as a serious amount to complement scholarships or loans as I do masters and a PhD. And I'd be ecstatic if I could avoid scholarships or loans! And flutter would render possible writing such cross platform apps and maintaining them while studying, whereas learning, writing and maintaining two codebases, and spending money on premium hardware up front would be a very big obstacle for me, and also unmaintainable in the long run (I can't write a thesis and maintain compatibly two distinct codebases with such diverging paradigms, let aside multiple apps).
So I guess I'll end up in some time with a setup similar to yours, which I think is optimal: use my favourite setup, test on target platforms. A bit like cross-compiling.
Can someone compare their experience with Flutter or even React Native, versus writing separate platform-native Swift/Java versions for iOS and Android?
I don't often hear about the true accounting of time spent learning and grappling with the limitations of cross-platform frameworks, including debugging and workarounds, versus just using the platform vendor tools.
It just sort of seems like it's assumed that it's a huge time waste to maintain separate codebases. But I wonder if you gain other advantages that might outweigh it, like not having to "fight" the intermediary layer and getting first-class access to the underlying APIs, platform features and debugging tools. Thoughts?
I’ll bite. I write a simple free surf forecast app for my local region with around 1000 active users. I am currently rewriting the app because I have time and ideas.
I am writing the same app in both Flutter and Swift/objc simultaneously, and I will grant that I am much better iOS dev than Android. The previous version of the Android app was written in Java.
Honestly, Android dev for me is very not fun, there is so much mental load that is probably necessary for large apps but for me it’s just a time sink. Flutter on the other hand gives me Material widgets our of the box and easy declarative layouts. I will say this is my first experience working in the react paradigm and it’s been a learning curve. Flutter is super fun to play with though and making user interfaces is actually pleasant.
I decided to also write the new version natively on iOS because some of the most important parts of the app for me are the Today Widget and Watch Complication. Now with Flutter you can add this manually in swift or objc or whatever, but they can’t talk to Dart code. So I would have to essentially write the networking client code twice. That, and the iOS widget support just isn’t good enough for me in Flutter.
So I am using Flutter to develop and Android version of my app, while keeping the option that it could eventually become a full cross platform version someday if I choose.
Also if Dart ever gets extensions like Kotlin and Swift that would be a game changer for me, since I use generated specs for my API schemes.
I can speak to some of the pros and cons of two codebases for ios and android that share a common api service on a semi-large production app with 6k to 10k constant users. Pros:
- Native performance and API exposure for both, without a wrapper/glue layer. That's it.
Cons: Feature implementation complexity and nuanced differences that leads to one version having a bug the other doesn't, or they both have the bug but for different reasons.
- dependency updates, testing workflows, build and deployment tool chains, actually all tooling - is different for both.
- syncing development between teams is a nightmare.
- delivery time on releases becomes two deadlines, and stakeholders don't understand why both versions can't always be complete on the same exact day.
- ui implementation, and organization of graphical assets are just plane different.
- device support, and user support in general, must account for basically any supported ios or android vendor hardware/os
there's a lot of enthusiasm, yet, i feel less enthusiastic about Flutter after reading this.
i had not thought about this right in the past. i hadn't factored in the reality of needing to maintain two separate UI trees, one with Material Design widgets and one with Cupertino widgets. this makes me think one of the really big advantages i thought Flutter had -- a unified UI -- is not really realistic.
Hi there, I'm the author of the article. I'd like to clarify that it's not bad at all. Libs exist out there, such as offering a cross platform nav bar, seemless where you wouldn't have to maintain two separate codebases. Also for things like forms, if you have a custom design, you won't be having a lot of "if/else" statements, you'd simply use one set of widgets since they'd be custom.
I totally understand the upside of writing one app for both platforms, but at the end of the day they are still two different platforms. It seems unlikely you’re going to make a high quality app unless you give each version the individualized attention they really need.
Maybe these dual platform frameworks are fine for something like a company internal app where it’s okay if you don’t get everything “just right”. But otherwise I’d rather just go pure native, even if it means alienating half my user base or spending 2x resources. It’s worth it in most cases IMO.
Granted I’ve only spent a couple weeks with React Native about a year ago, so maybe I just need to give it another go.
I'd really recommend taking a dive into flutter. It's leaps and bounds better than working with React Native IMO.
Treating Dart and Flutter as one 'SDK/Language for Apps' made it a lot easier to avoid the uncanny valley effect I had with react native vs normal react.
It doesn't make sense to alienate half your user base if your product is anything other than a standalone app with no real-world hardware or services. In this case you're not competing on app slickness like you would be with a calendar app or something.
I am working on an Flutter android app, I find it still very laggy. Even the official Gallery app from flutter team laggy. I am hoping they will sort it out by the time they release it from beta.
The article mentions removing simple elements, e.g. "‘Center’ widget is nice for a Hello, World container but I never understood it. Why can’t ‘Container’, something that’s way more prevalent have a property to do the same thing?"
I'm perfectly happy with the nesting of simple elements. Having a single 'Container' also handle various layout rules is what makes all the positioning options of CSS difficult. Similarly for constraint systems. Composable, single function components are easy to learn and use. I'm just presuming that it has good runtime characteristics and haven't run into any issues yet.
58 comments
[ 15.6 ms ] story [ 1446 ms ] threadIf so, why not Ionic?
Probably 6 months ago flutter wouldn't be on this list but Google has surprisingly shown strong support
IIRC, Flutter started at Google.
There are a couple of notable exceptions but the list of abandoned developer tools coming out of Google is far longer.
Given you're doubling down you're taking a massive risk as a business. As an employee you also risk making yourself unemployable going all in on Dart and Flutter.
Why not Xamarin? It also has the backing of a top software company.
I prefer not to think of myself as an X-language programmer. And yes, when I was developing mobile apps, I did it solo. I preferred to choose the right tool for the job, and learn a new language if needed.
And I think Xamarin is better than React Native or Flutter, because Xamarin makes it easy to use each platform's full set of native widgets in the native way, while still sharing non-UI code. In contrast, React Native does use a subset of native widgets, but doesn't give you access to the full set of them (at least out of the box), kind of like the old Java AWT. And like Swing or JavaFX, Flutter throws out the native widgets entirely.
Xamarin is terrible to work with, and if AngularDart shares code with Flutter then it might be interesting to replace angularJS + Xamarin with dart.
I only clicked this article because I a Danish municipality programmer, I follow, comment on flutter, on one of the Microsoft news portals though, so the community is definitely a lot smaller than the Xamarin.
The problem with React Native is that the complexity is higher, routing/navigation a mess on iOS and the dev experience is nowhere near as fast or polished as Flutter’s.
My strong suggestion is to invest a week with your team to learn React Native and then spend a week with Flutter. A week is enough to pick them up.
The use of widgets saves a lot of time, leaving one to focus on connecting everything together. It's also easier to learn than React Native (for me at least).
The current downside for me has been the lack of maps (I'm aware of current efforts). I also hit a weird Firebase Messaging bug that leads to an infinite loop of the app opening itself [0].
I agree with the author regarding the strong Firebase push. The community doesn't yet seem large enough, so outside of wine of the Google supported plugins, it's sometimes a struggle.
I am building a second app in Flutter, using the new Material stuff that Google announced this year.
[0] https://github.com/flutter/flutter/issues/18524
But it actually makes sense on a closer look. Dart on the server is not officially supported, as the primary focus of Dart is use as a client-side language, so it would be a bit confusing for the Flutter documentation to recommend using Dart for a backend.
That being said, I think Flutter is a great platform for quickly building apps, and getting consistent behavior across different vendors. I think that it can only continue to get better.
What gives you that idea? The Dart VM is listed on the platform page for command line and server side programs. https://www.dartlang.org/guides/platforms
The focus of Dart 2 and beyond is the client side [0].
You can definitely run Dart in the VM, but beyond the HttpServer API, server-side support is mostly a community effort.
My point isn't that this is a bad thing, it's that it makes sense for Firebase to be promoted because Dart doesn't have _official_ server-side support.
[0]: https://medium.com/dartlang/announcing-dart-2-80ba01f43b6
I do agree they have pivoted to a more client-sided branding though.
Analogy: JavaScript is focused on the client too, but people also use it on the server.
It is more nuanced: Dart on the server side is supported, but the development focus is on the client-side stories (Flutter and Angular).
Google's Dart team develops e.g. the Dart VM which is great for server workloads too, they do provide some server-side libraries, but they themselves don't work on third-party database drivers (for now).
Think of it as the question of focus: they want to focus on the client-side story, get it right, and then deal with the rest. Spreading thin won't help either.
To me , dart on the server , with their agent / isolate based concurrency as well as async await language support, provides ( in theory ) one of the most exciting environment to develop backends on.
But Google's Dart team is not actively involved in developing e.g. the Postgres driver, it is done by an independent company who is building their stack on server-side Dart.
Btw. I agree: the isolate-based concurrency + language tools is really great for server-side Dart apps. I use it in a highly concurrent data setup, and I wouldn't switch to other language.
From Google's point of view, we would all be using it.
https://github.com/google/flutter-desktop-embedding
Termux would probably also be mostly usable in Fuchsia, WSL or Aix.
Maybe it's possible to do with a pc running chromium os.
https://flutter.io/flutter-for-react-native/
Unfortunately, even Flutter requires it when building the production-ready Android version of the app. Perhaps it's time Google switched to their own Bazel as the default for building Android apps. As a bonus, the syntax is a lot lighter than Apache Groovy's.
I don't know Gradle, I'll try when I have free time. I have one project which can be better off as a Java API app (based mostly on Intents). WRT Flutter, I have not experienced any performance problems with it so far; though I haven't built a "production-ready app" yet. But given it'd mostly be a rare task, that'd be bearable.
WRT Macs, well, I use a Unixy laptop since time immemorial, one way or another (stuff I spent >1yr with: Ubuntu, Arch, FreeBSD, Xubuntu, and finally and currently Debian; in that order), and being quite content with what I have at hand, I'd be reluctant to switch anyways. But AFAIK the App Store is where the money is, so I want to get in to it ASAP.
I'm in a rare situation where I'm a long time amateur/semi-professional programmer, but I study and plan an academical career in humanities. I need to write up a couple apps to help interacting with documents (what's available on mobile is basically sub-par), so I'll code them up anyways, but I'd be glad if I could share them FOSS but also get some amount of money from the app stores. Even a hundred or two hundred dollars a month would help as a serious amount to complement scholarships or loans as I do masters and a PhD. And I'd be ecstatic if I could avoid scholarships or loans! And flutter would render possible writing such cross platform apps and maintaining them while studying, whereas learning, writing and maintaining two codebases, and spending money on premium hardware up front would be a very big obstacle for me, and also unmaintainable in the long run (I can't write a thesis and maintain compatibly two distinct codebases with such diverging paradigms, let aside multiple apps).
So I guess I'll end up in some time with a setup similar to yours, which I think is optimal: use my favourite setup, test on target platforms. A bit like cross-compiling.
edit: grammor
I don't often hear about the true accounting of time spent learning and grappling with the limitations of cross-platform frameworks, including debugging and workarounds, versus just using the platform vendor tools.
It just sort of seems like it's assumed that it's a huge time waste to maintain separate codebases. But I wonder if you gain other advantages that might outweigh it, like not having to "fight" the intermediary layer and getting first-class access to the underlying APIs, platform features and debugging tools. Thoughts?
I am writing the same app in both Flutter and Swift/objc simultaneously, and I will grant that I am much better iOS dev than Android. The previous version of the Android app was written in Java.
Honestly, Android dev for me is very not fun, there is so much mental load that is probably necessary for large apps but for me it’s just a time sink. Flutter on the other hand gives me Material widgets our of the box and easy declarative layouts. I will say this is my first experience working in the react paradigm and it’s been a learning curve. Flutter is super fun to play with though and making user interfaces is actually pleasant.
I decided to also write the new version natively on iOS because some of the most important parts of the app for me are the Today Widget and Watch Complication. Now with Flutter you can add this manually in swift or objc or whatever, but they can’t talk to Dart code. So I would have to essentially write the networking client code twice. That, and the iOS widget support just isn’t good enough for me in Flutter.
So I am using Flutter to develop and Android version of my app, while keeping the option that it could eventually become a full cross platform version someday if I choose.
Also if Dart ever gets extensions like Kotlin and Swift that would be a game changer for me, since I use generated specs for my API schemes.
i had not thought about this right in the past. i hadn't factored in the reality of needing to maintain two separate UI trees, one with Material Design widgets and one with Cupertino widgets. this makes me think one of the really big advantages i thought Flutter had -- a unified UI -- is not really realistic.
i must be misunderstanding this
So, I just got that excitement from having something cool to learn.
Maybe these dual platform frameworks are fine for something like a company internal app where it’s okay if you don’t get everything “just right”. But otherwise I’d rather just go pure native, even if it means alienating half my user base or spending 2x resources. It’s worth it in most cases IMO.
Granted I’ve only spent a couple weeks with React Native about a year ago, so maybe I just need to give it another go.
Treating Dart and Flutter as one 'SDK/Language for Apps' made it a lot easier to avoid the uncanny valley effect I had with react native vs normal react.
I'm perfectly happy with the nesting of simple elements. Having a single 'Container' also handle various layout rules is what makes all the positioning options of CSS difficult. Similarly for constraint systems. Composable, single function components are easy to learn and use. I'm just presuming that it has good runtime characteristics and haven't run into any issues yet.