Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment(blog.codemagic.io)
blog.codemagic.io
Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment
https://blog.codemagic.io/flutter-vs-ios-android-reactnative-xamarin/
185 comments
Isn't there the danger that Apple just forbids/bans this remote code reloading/replacement to protect their users? I mean it's a loophole that can get abused (and likely is) for stuff that wouldn't make it through the review process in first place..
Not sure about the flutter/react native situation but dynamic code must only use webkit and JavaScript core so that Apple can ensure your application isn't accessing private APIa via a remote code update.
https://developer.apple.com/news/?id=09062019b
https://developer.apple.com/news/?id=09062019b
Definitely crossed my mind. It'd be easy enough to submit a legitimate app and then modify the content it serves to be something malicious. No idea if/when a follow up review might catch that outside of user reporting.
But in the scenario where apple decides to no longer allow OTA updates, you're just back to the extended review process that native apps have to go through, so I think the productivity gains make it worthwhile.
But in the scenario where apple decides to no longer allow OTA updates, you're just back to the extended review process that native apps have to go through, so I think the productivity gains make it worthwhile.
I always wondered why Someone doesn’t make a YouTube like app that connects to content repositories via end to end encryption so Apple can’t see what content you are accessing. You could connect to something like Khan Academy for educational videos. This would also allow you to connect to Pornhub or something similar in a native experience without Apple being able to stop it.
You mean something like a Web browser?
I think letting users find and select content is the only way to avoid getting banned. As soon as the app does anything to nudge users toward a particular kind of content it risks getting banned.
I think letting users find and select content is the only way to avoid getting banned. As soon as the app does anything to nudge users toward a particular kind of content it risks getting banned.
Yes you can do that, and get banned as soon as Apple finds out.
There's a huge area of seemingly obvious user-centric products that don't exist simply because there isn't a working business model to support it.
I mean VLC already exists and it can stream videos from the websites that you point it at. I’d guess the only think it’s missing at this point is youtube-dl integration.
[deleted]
OP mentions the Provider package [1] wasn't around when they did the Flutter version. That is really too bad, because it is absolutely the best way to manage state in Flutter. It makes things so much easier and cleaner than the other methods.
[1] https://github.com/rrousselGit/provider
Edit: I probably would have even gone back and refactored the app to use Provider before publishing the article. =) That would have been a nice additional bit of information for the reader.
[1] https://github.com/rrousselGit/provider
Edit: I probably would have even gone back and refactored the app to use Provider before publishing the article. =) That would have been a nice additional bit of information for the reader.
Looks like lots of things didn't exist then for each framework which made a lot of the issues he encountered easier: SwiftUI, React Hooks/useContext, Jetpack. I'd like to see a revisit of this whole project.
I was glad I found Provider after almost diving into BLoC. The less boilerplate and context switching the better.
Wow this looks interesting, I don't know why it has slipped right past me so far.
This is super interesting, but the problem I have is that this guy's eye for design leaves a lot to be desired. When was the last time someone built a clunky table directly into the UI and added fully styled table rows dynamically? Why not modernize the design, and use a styled list view with a data adapter and try this again on each platform? It didn't surprise me at all that he struggled with the table in basically every scenario. There's a reason (or two) they've fallen out of fashion, imo, and it sort of clouded the assessment of everything for me, since he kept mentioning struggling with the table.
As an Android developer I looked at the code he wrote and felt bad for him. Of course it was painful trying to set all your styling up programmatically for the table! Use a viewholder pattern and a recyclerview/adapter then throw your data into the adapter. Make a simple xml file for your rows and inflate those into the viewholder then you're good to go! None of these clumsy declarative attempts to do what xml does well.
It's still a great write-up, but that part hurt me.
It's still a great write-up, but that part hurt me.
This is exactly the kind of thing that is unnecessarily hard in non-React-like UI frameworks. XML definitely does not do this well!
In React Native or Flutter I can just declaratively go from an array to rows of UI. It will be a few lines of code and will be incredibly clear (and easy to change).
In Android or iOS I can either do something procedural (which is messy, hard to reason about etc) or do something horrifyingly boilerplate-y (as you suggest), spreading things across multiple files and greatly increasing cognitive load.
I've worked with native Android, native iOS, React Native and (a tiny bit) with Flutter. I really wouldn't use vanilla native Android or iOS (even for a single platform app) unless there were some particular requirements around perf or whatever; so much more tedious, slower and (this one is subtle and will be missed by simple comparisons) so, so much harder to go back and make changes or additions to.
SwiftUI and Jetpack compose look promising for the future. But neither are ready for mainstream (enterprise?) use today.
In React Native or Flutter I can just declaratively go from an array to rows of UI. It will be a few lines of code and will be incredibly clear (and easy to change).
In Android or iOS I can either do something procedural (which is messy, hard to reason about etc) or do something horrifyingly boilerplate-y (as you suggest), spreading things across multiple files and greatly increasing cognitive load.
I've worked with native Android, native iOS, React Native and (a tiny bit) with Flutter. I really wouldn't use vanilla native Android or iOS (even for a single platform app) unless there were some particular requirements around perf or whatever; so much more tedious, slower and (this one is subtle and will be missed by simple comparisons) so, so much harder to go back and make changes or additions to.
SwiftUI and Jetpack compose look promising for the future. But neither are ready for mainstream (enterprise?) use today.
I mean if you want 3 identical rows to just statically be at the bottom of a view you can always define the row in XML then put it in a vertical LinearLayout at the bottom using the <include> tag. You maintain modularity without cumbersome code to deal with.
This has the added benefit of being able to see the views without having to compile your code.
This has the added benefit of being able to see the views without having to compile your code.
Please try out one of Flutter or React Native. I think you’ll be surprised how much nicer they are for anything like this. The code is certainly not cumbersome when compared to the equivalent XML.
Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.
Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.
You, and everyone else who makes this argument seems to blatantly dismiss the tooling around Android, specifically Android Studio and the layout preview panel. The person you are responding to is talking about editing UI layouts in XML, using the preview panel, without building the project at all.
Everyone loves to talk about "hot reloading" and obsess over reducing build times incrementally as if that's the only way to develop anything faster. No matter how fast your "hot reload" is, it'll never beat the layout preview panel in Android Studio, which is directly rendering your xml in real time, without compiling or building anything.
Everyone loves to talk about "hot reloading" and obsess over reducing build times incrementally as if that's the only way to develop anything faster. No matter how fast your "hot reload" is, it'll never beat the layout preview panel in Android Studio, which is directly rendering your xml in real time, without compiling or building anything.
For static layouts this can work pretty well. I think it is still typically a bit slower/more awkward. And often harder to change. (I actually have most experience with native Android.)
Android Native also has hot reload, what on earth are you on about?
You get both with Android Native, layout preview and hot reloading.
You get both with Android Native, layout preview and hot reloading.
I was addressing the comment and in no way claimed Android doesn’t have a hot reload solution.
In my first job as android developer (circa 2010) I was tasked with porting a J2ME application with 30,000 lines of code in total to Android. Their primary condition was 'I shouldn't use any XML for layouts and any UI element should be defined only via code'.
I later understood that, it was because they wanted to use the J2ME-to-android bridge I develop for their other J2ME apps and XML layout dependencies would have been a hindrance. Since, this was very early in the android development ecosystem and many devs were Java developers before; usage of XML layouts for UI wasn't strictly mandated as it is now. I did complete the bridge in 3 months and the application performed as it should.
But, I'm glad I never had to do everything related to UI programatically on Android ever after.
I later understood that, it was because they wanted to use the J2ME-to-android bridge I develop for their other J2ME apps and XML layout dependencies would have been a hindrance. Since, this was very early in the android development ecosystem and many devs were Java developers before; usage of XML layouts for UI wasn't strictly mandated as it is now. I did complete the bridge in 3 months and the application performed as it should.
But, I'm glad I never had to do everything related to UI programatically on Android ever after.
I only understood why this code is so poor when I understood what the author has been doing : trying to write flutter code on Android.
If anything, they would have had a way easier time using Compose, since its principles are reminiscent of the ones of flutter.
Or if they had just read a beginner guide or two :/
If anything, they would have had a way easier time using Compose, since its principles are reminiscent of the ones of flutter.
Or if they had just read a beginner guide or two :/
Hi, slightly unrelated to the thread, but do you have any resources you can recommend for modern Android UI development? (besides the basic google resources/ codelabs...etc)
Unfortunately I cannot. I've mostly taught myself by reading exactly those same specs you're talking about and watching a lot of YouTube.
I know I'm a thoroughly inadequate Android developer because I've only ever worked on a small team at a small company and have had 0 tutelage, but what I've taught myself in the past 3 years boils down to:
Libraries to use: Retrofit, RxJava, Dagger2, Room
Use AndroidX over support/compat whenever you can.
Kotlin is amazing, though I'm still learning. If you know Java then Kotlin makes a lot of sense.
Use constraint layouts so that when you try to dabble with AndroidX motion layouts you'll have an easier time.
MVVM is commonly accepted architecture, and I like it personally.
Use single activity architecture: 1 activity with many fragments is the industry standard (or it should be). Some exceptions exist but mostly that's how it works.
XML files are your friends and editing them directly is faster and often easier than the Visual Builder in Android Studio.
Be sure that when you install the emulator you have it integrating with HAXM or HyperV or whatever they have it integrate with these days: it'll make debugging on the emu a lot less painful.
I know I'm a thoroughly inadequate Android developer because I've only ever worked on a small team at a small company and have had 0 tutelage, but what I've taught myself in the past 3 years boils down to:
Libraries to use: Retrofit, RxJava, Dagger2, Room
Use AndroidX over support/compat whenever you can.
Kotlin is amazing, though I'm still learning. If you know Java then Kotlin makes a lot of sense.
Use constraint layouts so that when you try to dabble with AndroidX motion layouts you'll have an easier time.
MVVM is commonly accepted architecture, and I like it personally.
Use single activity architecture: 1 activity with many fragments is the industry standard (or it should be). Some exceptions exist but mostly that's how it works.
XML files are your friends and editing them directly is faster and often easier than the Visual Builder in Android Studio.
Be sure that when you install the emulator you have it integrating with HAXM or HyperV or whatever they have it integrate with these days: it'll make debugging on the emu a lot less painful.
I learned Native Android via Udacity courses. I did all of them in two months. Teaches from beginner level and goes to Advanced stuff gradually.
This. Unless you work on internal projects, more than likely you’re going to have to dig much deeper to achieve custom styling and animations. I only have experience in iOS, Android and react native, but it’s so much easier to get there with react native. It would have been more useful to see how other cross platform solutions deal with custom styles and come to a conclusion that includes trade offs between them.
I think building a toy app for yourself is among the best ways to decide for yourself which framework to go with!
The conclusions from the article were:
> Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks. Their Hot Reload functionality also sped up the development cycle a lot.
> I was able to create the Flutter app faster than the React Native app, but that’s because I had more experience with Flutter than with React Native. I also didn’t know how to manage state properly in the React Native. That’s why declare both Flutter and React Native the winners of this experiment.
For performance, Bram wrote:
> It’s obvious that the CPU-usage of the Flutter application is smaller than that of the React Native and Xamarin Forms applications, and that’s why I declare Flutter the winner of this experiment.
> In the second experiment it was concluded that the Flutter application was less taxing on the CPU than the React Native and Xamarin Forms applications. This doesn’t automatically prove that Flutter is more performant than React Native or Xamarin Forms.
> There are a lot of features that the Cocktailr app doesn’t have, like caching for example. That would reduce the amount of network requests that need to be made and would make the app more performant, meaning that it could lead to different results. I also only used CPU-usage as a performance indicator. I don’t have any data on the memory or battery consumption for example. These are also an important performance indicators.
We at Wanderlog (https://wanderlog.com) are using React Native largely because the ecosystem around it is a bit more mature than Flutter's at the moment. It's definitely saved us time vs. writing native code. We've definitely run into issues, and I think the main things we'd want to test as alternate performance indicators if we were choosing a framework again are:
1. How performant/easy-to-implement are long scrolling lists
2. How easy is it to animate the dimensions of Views that affect layouts of other views
3. How many libraries are there for things that will be dealt with native code? Dealing with the boundary with native code is always going to be tough
The conclusions from the article were:
> Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks. Their Hot Reload functionality also sped up the development cycle a lot.
> I was able to create the Flutter app faster than the React Native app, but that’s because I had more experience with Flutter than with React Native. I also didn’t know how to manage state properly in the React Native. That’s why declare both Flutter and React Native the winners of this experiment.
For performance, Bram wrote:
> It’s obvious that the CPU-usage of the Flutter application is smaller than that of the React Native and Xamarin Forms applications, and that’s why I declare Flutter the winner of this experiment.
> In the second experiment it was concluded that the Flutter application was less taxing on the CPU than the React Native and Xamarin Forms applications. This doesn’t automatically prove that Flutter is more performant than React Native or Xamarin Forms.
> There are a lot of features that the Cocktailr app doesn’t have, like caching for example. That would reduce the amount of network requests that need to be made and would make the app more performant, meaning that it could lead to different results. I also only used CPU-usage as a performance indicator. I don’t have any data on the memory or battery consumption for example. These are also an important performance indicators.
We at Wanderlog (https://wanderlog.com) are using React Native largely because the ecosystem around it is a bit more mature than Flutter's at the moment. It's definitely saved us time vs. writing native code. We've definitely run into issues, and I think the main things we'd want to test as alternate performance indicators if we were choosing a framework again are:
1. How performant/easy-to-implement are long scrolling lists
2. How easy is it to animate the dimensions of Views that affect layouts of other views
3. How many libraries are there for things that will be dealt with native code? Dealing with the boundary with native code is always going to be tough
I tried writing a small app using Flutter. It was really a fantastic experience IMO.
To answer some of your questions:
1. Long lists are pretty painless to implement. There a some helper views included for building list views that aren't backed by in memory lists, and they feel really nice and fluid (https://api.flutter.dev/flutter/widgets/ListView/ListView.bu...)
2. Flutter has lots of built in animation support. Almost every aspect of a view is animatable out of the box (see https://api.flutter.dev/flutter/widgets/AnimatedContainer-cl... for an example). I definitely got carried away with the animations because of how fun and easy they were!
3. I had to deal with native code for push notifications, sharing flows, and universal links. Google publishes libraries for dealing with a lot of the common stuff, and there's great community support as well.
To answer some of your questions:
1. Long lists are pretty painless to implement. There a some helper views included for building list views that aren't backed by in memory lists, and they feel really nice and fluid (https://api.flutter.dev/flutter/widgets/ListView/ListView.bu...)
2. Flutter has lots of built in animation support. Almost every aspect of a view is animatable out of the box (see https://api.flutter.dev/flutter/widgets/AnimatedContainer-cl... for an example). I definitely got carried away with the animations because of how fun and easy they were!
3. I had to deal with native code for push notifications, sharing flows, and universal links. Google publishes libraries for dealing with a lot of the common stuff, and there's great community support as well.
>his proves how much time you save by using cross-platform frameworks
not sure it proves much since the author went about this in a really really weird way.
From the snippets shown, this is extremely unidiomatic Android code, it looks a lot more Flutter code. which makes sense since the author seems like they were trying to write Flutter code on another platform.
And even if they went about it in a more productive way, I am not sure what the feedback of one beginner dev having spend 20 hours on each platform is supposed to mean about anything.
not sure it proves much since the author went about this in a really really weird way.
From the snippets shown, this is extremely unidiomatic Android code, it looks a lot more Flutter code. which makes sense since the author seems like they were trying to write Flutter code on another platform.
And even if they went about it in a more productive way, I am not sure what the feedback of one beginner dev having spend 20 hours on each platform is supposed to mean about anything.
My experience with Flutter is that you need a lot less native code than you do with React Native.
However, the hands down best part is the tooling. Unlike on react native everything just works on Flutter. It doesn't feel nearly as fragile.
However, the hands down best part is the tooling. Unlike on react native everything just works on Flutter. It doesn't feel nearly as fragile.
I scanned through your two articles (part 1 and part 2) and wanted to read more about scope. Although I do find your experiments interesting, scope is really the question. At small scale (single developer with a few view controllers and models), your experiments might make sense but when talking about scaling, I don't think your UI and performance results are relavent. How does a project with hundreds of views, models and libraries scale with Flutter vs. native iOS vs. React Native? How easy is the codebase to browse and learn from 0 to 100? Sure, one can use Flutter when they're playing with a project but when you scale towards 5-20 mobile developers, does it make sense? That's more of an interesting question to me...
But a lot harder to address (probably effectively impossible). This is actually one of the best comparisons I’ve seen.
Are apps with hundreds of views common enough that the flutter workflow with hundreds of views something to consider
An app I’ve seen with a lot of views is grab but I don’t think they number in the hundreds.
Was hoping to see a comparison with https://www.nativescript.org/
This needs to be higher up -- Nativescript is Flutter's biggest competition and IMO it's better than Flutter, because it doesn't require investing in Dart and switching to the Flutter "ecosystem" completely.
Didn't know about Nativescript. Did you try it already?
Yup, I used it on a client application the first time I used it and it worked very well. The project was finished a while ago, and Nativescript has made leaps and bounds in that time, it's even better today.
I used Nativescript-Vue[0] which has since been brought under the nativescript umbrella fully, and it was a great experience. Vue is drastically less complex than React and that translated to very easy app building.
I don't build mobile apps (I think the market is somewhat saturated), but if I had to, I wouldn't even consider Flutter these days (I've built a small app in that as well), or building natively (who wants to be an "android developer" these days if you don't want to specialize in it?) -- Nativescript all the way.
There's also stuff like svelte-native[1] -- Nativescript is a better platform to build on than React Native. Props to the React Native team for being the first to have the idea (same goes with the component-driven design of react itself, though arguably backbone/marionette views were first), but Nativescript is a much more flexible and easy to use solution.
[0]: https://nativescript-vue.org/
[1]: https://svelte-native.technology/
I used Nativescript-Vue[0] which has since been brought under the nativescript umbrella fully, and it was a great experience. Vue is drastically less complex than React and that translated to very easy app building.
I don't build mobile apps (I think the market is somewhat saturated), but if I had to, I wouldn't even consider Flutter these days (I've built a small app in that as well), or building natively (who wants to be an "android developer" these days if you don't want to specialize in it?) -- Nativescript all the way.
There's also stuff like svelte-native[1] -- Nativescript is a better platform to build on than React Native. Props to the React Native team for being the first to have the idea (same goes with the component-driven design of react itself, though arguably backbone/marionette views were first), but Nativescript is a much more flexible and easy to use solution.
[0]: https://nativescript-vue.org/
[1]: https://svelte-native.technology/
How's the development experience? Can you debug/step-in to the code?
You can[0] -- that's one of the upsides to the web as a platform, you get to use some familiar tools to debug the JS side of things.
Also, I'd honestly argue at you that development is so fast for Nativescript (especially when you start using Hot Module Replacement[1]) that you could get away with print debugging.
And again, another really awesome thing is that nativescript integrates really well with native code -- you can write your game/native-feature-heavy screen in native java/kotlin/swift/objc and just write every other screen with nativescript. Flutter makes that just a smidge harder to do because of how it integrates (drawing every pixel) -- it's possible[2], but my money is on Nativescript being better at it.
[0]: https://docs.nativescript.org/tooling/debugging/debugging
[1]: https://www.nativescript.org/blog/nativescript-hot-module-re...
[2]: https://api.flutter.dev/flutter/widgets/AndroidView-class.ht...
Also, I'd honestly argue at you that development is so fast for Nativescript (especially when you start using Hot Module Replacement[1]) that you could get away with print debugging.
And again, another really awesome thing is that nativescript integrates really well with native code -- you can write your game/native-feature-heavy screen in native java/kotlin/swift/objc and just write every other screen with nativescript. Flutter makes that just a smidge harder to do because of how it integrates (drawing every pixel) -- it's possible[2], but my money is on Nativescript being better at it.
[0]: https://docs.nativescript.org/tooling/debugging/debugging
[1]: https://www.nativescript.org/blog/nativescript-hot-module-re...
[2]: https://api.flutter.dev/flutter/widgets/AndroidView-class.ht...
How is it different from being the angular / vue.js edition of react native? Does it implement its own render & view layer in c++ like flutter does?
No but it introduces a complete shim of the native platform underneath -- as in your can write and execute JS that moves native code underneath. React Native doesn't support this currently (and has no plans to).
There's also the possibility of using vastly lighter weight frameworks, for example svelte-native[0] which should be quite a bit more responsive.
[0]: https://svelte-native.technology/
There's also the possibility of using vastly lighter weight frameworks, for example svelte-native[0] which should be quite a bit more responsive.
[0]: https://svelte-native.technology/
So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs.
Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
> So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs.
This is definitely one of the best parts of Flutter -- the fact that they've done the tremendous work of making a framework that draws every pixel to the screen is amazing, but that's also a liability. Android/iOS has an ecosystem of things that you can
One thing I ran into during flutter development was that the SQLite library[0] did not support off-device use -- I couldn't even run tests locally without putting them on the device. Maybe that's changed in recent memory, but that really turned me off to it.
There's also the difficulty of acclimating to the BloC paradigm[1][2]. If you hear it explained it seems simple, and then you try to write some code with it and confusion ensues -- it's like flux mixed with FRP-style stream programming and that's the official answer from the Flutter team. Everyone is confused by it and it isn't the easiest thing you could do but the other answers aren't that great either.
> Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
So that's the thing -- if you really need native performance (you don't, most of the time, especially most apps are almost web pages). You can write and integrate completely native views with Nativescript, and in fact you can build them with JS because Nativescript has shimmed the entirety of the native APIs -- you can write code like `const intent = new Intent(...);` in JS and get an android-native Intent object. Of course, you can also call native APIs easily when you need the power.
[0]: https://pub.dev/packages/sqflite
[1]: https://stackoverflow.com/questions/54114144/bloc-flutter-an...
[2]: https://medium.com/flutterpub/architecting-your-flutter-proj...
This is definitely one of the best parts of Flutter -- the fact that they've done the tremendous work of making a framework that draws every pixel to the screen is amazing, but that's also a liability. Android/iOS has an ecosystem of things that you can
One thing I ran into during flutter development was that the SQLite library[0] did not support off-device use -- I couldn't even run tests locally without putting them on the device. Maybe that's changed in recent memory, but that really turned me off to it.
There's also the difficulty of acclimating to the BloC paradigm[1][2]. If you hear it explained it seems simple, and then you try to write some code with it and confusion ensues -- it's like flux mixed with FRP-style stream programming and that's the official answer from the Flutter team. Everyone is confused by it and it isn't the easiest thing you could do but the other answers aren't that great either.
> Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
So that's the thing -- if you really need native performance (you don't, most of the time, especially most apps are almost web pages). You can write and integrate completely native views with Nativescript, and in fact you can build them with JS because Nativescript has shimmed the entirety of the native APIs -- you can write code like `const intent = new Intent(...);` in JS and get an android-native Intent object. Of course, you can also call native APIs easily when you need the power.
[0]: https://pub.dev/packages/sqflite
[1]: https://stackoverflow.com/questions/54114144/bloc-flutter-an...
[2]: https://medium.com/flutterpub/architecting-your-flutter-proj...
Exactly. Seems here that there’s tons of Dart fanboys in this thread forgetting that most people code to solve a business problem in the most efficient way.
What Flutter has achieved is impressive, but I don't think it's reasonable to classify Dart as a good language in 2020 off the back of it -- the competition is just too good.
Dart feels like an older java in a time when java doesn't even feel like java (with the recent versions, along with other JVM options). For example, try and check out Dart's JSON serialization story[0], it's bad compared to Haskell, Rust and even Go. Dart was rewritten (Dart1 was a train wreck) and Dart2 still doesn't have the features that are expected. Who rewrites a language but doesn't add non-nullable types[1]??
The Dart team is full of smart people, and what they've created is certainly a feat of engineering, but the competition is just tough out there. I consider Typescript to be a better language to write (in this same space, since it's an option for Nativescript), and would consider Swift just barely better, and of course on android you have Kotlin (or Go) as a choice.
At this point I'm generally curious, what do Dart fanboys mark as the strengths of the language over others?
[0]: https://flutter.dev/docs/development/data-and-backend/json
[1]: https://github.com/dart-lang/sdk/issues/22
Dart feels like an older java in a time when java doesn't even feel like java (with the recent versions, along with other JVM options). For example, try and check out Dart's JSON serialization story[0], it's bad compared to Haskell, Rust and even Go. Dart was rewritten (Dart1 was a train wreck) and Dart2 still doesn't have the features that are expected. Who rewrites a language but doesn't add non-nullable types[1]??
The Dart team is full of smart people, and what they've created is certainly a feat of engineering, but the competition is just tough out there. I consider Typescript to be a better language to write (in this same space, since it's an option for Nativescript), and would consider Swift just barely better, and of course on android you have Kotlin (or Go) as a choice.
At this point I'm generally curious, what do Dart fanboys mark as the strengths of the language over others?
[0]: https://flutter.dev/docs/development/data-and-backend/json
[1]: https://github.com/dart-lang/sdk/issues/22
Don’t get me wrong but I know a lot of people that don’t use the right tool for the job. And people here are very biased towards Dart.
I was a software engineer coding objc and swift at a pretty well known publicly traded German company. If it wasn’t because of typescript/js I wouldn’t have been able to build my startup completely on my own supporting backend, web, iOS and Android.
I was a software engineer coding objc and swift at a pretty well known publicly traded German company. If it wasn’t because of typescript/js I wouldn’t have been able to build my startup completely on my own supporting backend, web, iOS and Android.
> And people here are very biased towards Dart.
"Here" as in HN? Some of the comments on every Flutter post are people complaining about Dart, "why didn't you choose Kotlin," etc.
"Here" as in HN? Some of the comments on every Flutter post are people complaining about Dart, "why didn't you choose Kotlin," etc.
I mean I'm definitely one of those people, I have my unreasonable biases, but I just don't see (yet) the reasons behind the Dart bias. I'd love to learn more about it.
And yeah, what's crazy is that in recent time you could know tyepscript/js and actually build every bit of a startup (assuming you know the domains well enough)... Dart as an investment just doesn't make sense when you've got a language like JS (IMO best paired with Typescript) that can go everywhere.
And yeah, what's crazy is that in recent time you could know tyepscript/js and actually build every bit of a startup (assuming you know the domains well enough)... Dart as an investment just doesn't make sense when you've got a language like JS (IMO best paired with Typescript) that can go everywhere.
so it's like Appcelerator ( https://news.ycombinator.com/item?id=21955066 ), which has been around since eons.
Measure power consumption and framerate (especially for scrolling scenarios) rather than CPU usage before making any performance claims for mobile.
Flutter uses the Chrome rendering engine (Skia) and scrolling is fully fluid (in release mode). React native uses native views (if implemented correctly) and is usually very fluid too
I tried a flutter app i found from the sample app catalog on the iOS store on an iphone X and the scroll wasn't really good (although the views were very basic).
Can you point me at an iOS app made with flutter that implements this correctly on the store ?
EDIT : it's the "veggie season" app and i've tried it again on my iphone 6. it's almost unusable. The scroll stops completley sometimes and other times it just scrolls randomly to places. It's just a scroll list of images. Nothing else. That's very troubling..
Can you point me at an iOS app made with flutter that implements this correctly on the store ?
EDIT : it's the "veggie season" app and i've tried it again on my iphone 6. it's almost unusable. The scroll stops completley sometimes and other times it just scrolls randomly to places. It's just a scroll list of images. Nothing else. That's very troubling..
This might be worth checking out: https://flutter.dev/showcase
Also this if you want to dig deeper: https://flutter-dashboard.appspot.com/benchmarks.html
I had the same experience.
Flutter devs like to throw some wild claims like "120 fps on mobile" even though no Android phone screen support 120 frames per second at the hardware level and that all the flutter apps I have seen stutter a lot in their animations.
Flutter devs like to throw some wild claims like "120 fps on mobile" even though no Android phone screen support 120 frames per second at the hardware level and that all the flutter apps I have seen stutter a lot in their animations.
"If you were to Google how to make network requests on Android you would discover all kinds of different packages and documentation." — my experience with Android: I will find 10 totally different ways to do it, and mostly not working, and the one that works you realize that it's outdated.
I've been considering trying out Flutter, but mainly due to my frustrations with React Native and I'm not entirely sure if others have had similar experiences or if Flutter would be any better. I have all kinds of issues with React Native tooling stability: code randomly reverts back to previous versions with hot reloading, things only partially update when I make changes, the same styles sometimes have inconsistent behavior, Flex doesn't always work the way that it should (justify-content is sometimes simply ignored for example) and things that should look the same on iOS and Android sometimes don't. So I guess my questions to those reading this are:
1. Have you had similar experiences using React Native?
2. Have you had these kinds of problems using Flutter as well?
I'm seriously considering rebuilding a prototype we have at work in Flutter in my spare time but I'd hate for it to be a similar situation to React Native where it appears to save me time at first and then fucks me over and only makes everything take more effort to get right.
I'm seriously considering rebuilding a prototype we have at work in Flutter in my spare time but I'd hate for it to be a similar situation to React Native where it appears to save me time at first and then fucks me over and only makes everything take more effort to get right.
Please, please try Flutter. I had literally the same issues with React Native and gave Flutter a test run late last year. I will never go back. Flutter is so stable and honestly my frustrations with Flex made consider giving up on mobile development. I think as a backend dev i really struggle with the layout aspects of mobile dev and flutter makes it so easy for me.
I'd say spend two nights playing with flutter. It took me that long to feel comfortable with Flutter's version of Components and state, but now it's a breeze. Hot reloading works great, it's easy to plug in native code if you need it, it's just amazing. I haven't been this excited about a language in years.
I'd say spend two nights playing with flutter. It took me that long to feel comfortable with Flutter's version of Components and state, but now it's a breeze. Hot reloading works great, it's easy to plug in native code if you need it, it's just amazing. I haven't been this excited about a language in years.
My experience is similar with yours. With React Native I had to fight just about everything on Android just to get everything working bearably. Hell, even some things like the profiler didn't work in Android when I was writing RN.
For now I'll stick to Flutter, it has simply awesome tooling. Everything just works. Dart, while not my favorite language, is also no more difficult than typescript to grasp, and they're inherently similar.
For now I'll stick to Flutter, it has simply awesome tooling. Everything just works. Dart, while not my favorite language, is also no more difficult than typescript to grasp, and they're inherently similar.
I think it would be an interesting experiment to have people with more expertise in each platform/tech write the code and then measure the developer time and performance.
This is because, based on what the author mentioned about cell reuse, they barely have any expertise in iOS. It would be hard to trust the code. Perhaps the author has provided access to the code?
This is because, based on what the author mentioned about cell reuse, they barely have any expertise in iOS. It would be hard to trust the code. Perhaps the author has provided access to the code?
One thing missing from the benchmarks was one on iOS. I'm curious how the cross platform frameworks compare to iOS native, since iOS apps are not garbage collected typically.
Also startup time is another interest to me, I've heard flutter apps tend to have slower startup times.
Also startup time is another interest to me, I've heard flutter apps tend to have slower startup times.
Me too, on both counts.
About a year and a half ago I compared native iOS tableview scroll performance to the Flutter "startup name generator" tutorial app. Flutter would noticably stutter occasionally, whereas native iOS was silky smooth.
Things may have changed since then..
About a year and a half ago I compared native iOS tableview scroll performance to the Flutter "startup name generator" tutorial app. Flutter would noticably stutter occasionally, whereas native iOS was silky smooth.
Things may have changed since then..
There are some issues here and there (JSX is not a language!) but this is definitely a very good comparison. It is indeed a little bit too shallow (give animations! Full app navigation stack management!) but gives practical insights.
Props to the author.
Props to the author.
Hyper Text Markup Language
If JSX isn't a language, then what is HTML?
If JSX isn't a language, then what is HTML?
JSX aka JavaScript XML. It is technically a language.
It’s an extension to a language. Would you call generics a language? Is TSX a different language from TypeScript?
<fanboy>Looking at Flutter vs React Native, the only comparison of interest for, perhaps most of us, Flutter for the win! Lower dev resources and way lower cpu usage. Dart is lovely, the docs are great, wide array of great UI widgets, and easy animation. As for hot reloading, well, you just have to experience the difference.</fanboy>
> Lower dev resources
Learning a completely new language in Dart to even get started with Flutter doesn't seem like low dev resources.
With React Native you are using:
- Javascript which most devs have a grasp on in 2020
- JSX which really isn't much different to HTML
- Styling is practically just CSS with slightly different property formatting and naming
If you've decided to go down the RN then theres a decent chance that your devs have used React before and there really isn't much between React and RN.
Learning a completely new language in Dart to even get started with Flutter doesn't seem like low dev resources.
With React Native you are using:
- Javascript which most devs have a grasp on in 2020
- JSX which really isn't much different to HTML
- Styling is practically just CSS with slightly different property formatting and naming
If you've decided to go down the RN then theres a decent chance that your devs have used React before and there really isn't much between React and RN.
- A million packages that never really seem to be in sync
- A ton of different ways to do the same thing (Expo or not for example)
- Documentation is always outdated
- You still have to deal with the most annoying part of native apps, namely compilation and certification. If it was a book it would have the title: "Native apps: the shitty parts"
- Doing the same thing twice with this package management and build system (or ten times...) can yield a different result
- JavaScript is an awful language, TypeScript makes it more tolerable but you can't really escape the problems JavaScript has
- A ton of different ways to do the same thing (Expo or not for example)
- Documentation is always outdated
- You still have to deal with the most annoying part of native apps, namely compilation and certification. If it was a book it would have the title: "Native apps: the shitty parts"
- Doing the same thing twice with this package management and build system (or ten times...) can yield a different result
- JavaScript is an awful language, TypeScript makes it more tolerable but you can't really escape the problems JavaScript has
<Also fanboy > Learning Flutter is really easy. I know everyone says it, but I encourage everyone to spend one Saturday trying to build some toy app with a single Google Maps screen or something. I fought with React Native for so long because it's dominant but I don't think I can ever go back. I never found myself getting truly comfortable with it or feeling like it did what I expected.
Im a backend dev so I really love that flutter will handle so much of the positioning of widgets/components on the screen AND give me a decent styling out the box and I only have to intervene if I want to. Thinking back to Grids and Flexbox makes my skin crawl lol.
Im a backend dev so I really love that flutter will handle so much of the positioning of widgets/components on the screen AND give me a decent styling out the box and I only have to intervene if I want to. Thinking back to Grids and Flexbox makes my skin crawl lol.
Xamarin and Qt also give me the same, with more useful industry programming languages.
That's neat, im just not much of a .NET person myself and I guess that using a language/framework that is enjoyable is more valuable to me than the portability aspect. I came into React Native for those portability reasons, and it wasn't enough to keep me excited about it. I don't see how Xamarin and .NET, which im even less into, would be different.
Also I'm not sure that Xamarain or QT are really very relevant, HNSVBubble or otherwise.
https://insights.stackoverflow.com/trends?tags=xamarin%2Crea...
Also I'm not sure that Xamarain or QT are really very relevant, HNSVBubble or otherwise.
https://insights.stackoverflow.com/trends?tags=xamarin%2Crea...
Both of which are now practically deaf on mobile. Flutter comes from Google, and while that doesn't guarantee it'll live, at least it has better potential.
They are only dead on the SV HN bubble kind of thing.
Dart also comes from Google and if it wasn't for Ad Words team it would be more dead than anything else.
Flutter is it very last opportunity to stay relevant.
Given that, I rather bet in dead technology with useful programming languages.
Dart also comes from Google and if it wasn't for Ad Words team it would be more dead than anything else.
Flutter is it very last opportunity to stay relevant.
Given that, I rather bet in dead technology with useful programming languages.
Hard disagree. Microsoft has practically abandoned Xamarin and is doing React Native themselves these days. Qt tried on mobile but never took off, there's hardly any mobile apps made with it and the few there are feel very out of place. Note that I really like Qt/QML so I wish it fared better -- please let me know if you have some success stories to share.
Flutter is the last option for Dart to stay relevant sure. You learn a programming language in a couple of days though so it just doesn't matter, and doesn't change the fact that in mobile world C# and C++ are just as irrelevant. I worked for years with C++, but I don't expect to ever again need it in a professional setting.
This is of course just from mobile perspective. Everywhere else Flutter is currently useless, and Qt/C# perhaps a good choice.
Flutter is the last option for Dart to stay relevant sure. You learn a programming language in a couple of days though so it just doesn't matter, and doesn't change the fact that in mobile world C# and C++ are just as irrelevant. I worked for years with C++, but I don't expect to ever again need it in a professional setting.
This is of course just from mobile perspective. Everywhere else Flutter is currently useless, and Qt/C# perhaps a good choice.
Microsoft has officially communicated many times, including at BUILD 2019 and .NET Conf, that React Native is for Web developers, and Xamarin for .NET developers.
They aren't one pony trick shop.
Qt didn't not take off for free beer mobile devs, it is doing alright for the kind of corporations that actually buy development tools.
Again we aren't talking about SV HN kind of bubbles here.
And I am betting Flutter won't save Dart, specially with Android team doing JetPack Composer and teaming with JetBrains on Kotlin/Native portability between iOS and Android.
Long term, PWAs with WebGL and WebAssembly will take it all.
They aren't one pony trick shop.
Qt didn't not take off for free beer mobile devs, it is doing alright for the kind of corporations that actually buy development tools.
Again we aren't talking about SV HN kind of bubbles here.
And I am betting Flutter won't save Dart, specially with Android team doing JetPack Composer and teaming with JetBrains on Kotlin/Native portability between iOS and Android.
Long term, PWAs with WebGL and WebAssembly will take it all.
The article topic was mobile development frameworks, so that was the basis for my judgement of Xamarin and Qt too. I do mobile development professionally, and Xamarin and Qt aren't current topics. It's basically only native vs. React Native, with Flutter recently challenging the React Native side on dev mindset but not yet on job opportunities.
Qt is used in corporations that buy development tools yes. But not for mobile, it's mostly embedded/medical/automotive. Xamarin peaked after Windows Phone died as the refuge of C# development, but React Native ate its crossplatform pie. Are they used? Sure, as a very small niche. But the fact is that currently companies with money build two native apps, and those with less money to throw around use React Native to target both platforms.
It's hard to get excited about web technologies replacing native apps when they've been upcoming contenders since around 2007 starting with Symbian. Maybe it happens one day, maybe it doesn't.
Qt is used in corporations that buy development tools yes. But not for mobile, it's mostly embedded/medical/automotive. Xamarin peaked after Windows Phone died as the refuge of C# development, but React Native ate its crossplatform pie. Are they used? Sure, as a very small niche. But the fact is that currently companies with money build two native apps, and those with less money to throw around use React Native to target both platforms.
It's hard to get excited about web technologies replacing native apps when they've been upcoming contenders since around 2007 starting with Symbian. Maybe it happens one day, maybe it doesn't.
On my market if JavaScript is at all considered, only Ionic comes into play.
Don't project your anecdotes in world wide projections.
Any numbers from Gartner reports or something, to prove how my little bubble is a niche?
Don't project your anecdotes in world wide projections.
Any numbers from Gartner reports or something, to prove how my little bubble is a niche?
For mobile non-game apps in app stores, targeting private people as users? If so, you then do have a very different market around there indeed. Let's not dig for market research reports, I don't really have the interest for that now. I'll just take your word for it.
Learning Dart is definitely not a large dev hurdle.
Most people (esp. js devs) can read dart and understand what it is doing without ever having even seen the code before.
I've found it takes an experienced engineer about two weeks to learn enough Go to be productive and Dart is honestly easier than that.
Most people (esp. js devs) can read dart and understand what it is doing without ever having even seen the code before.
I've found it takes an experienced engineer about two weeks to learn enough Go to be productive and Dart is honestly easier than that.
I have 20 C#/JS/SQL developers I want to put in a mobile project. So I’m supposed to eat an employee-year of salary to even consider Flutter+Dart?
Not gonna happen, especially with Google’s track record. Already been burned by the Angular v1 -> v2+ nightmare.
Not gonna happen, especially with Google’s track record. Already been burned by the Angular v1 -> v2+ nightmare.
[deleted]
If you are an iOS or Android developer already, learning dart vs the mess that is javascript seems more appealing. I would imagine something similar for non-JS backend developers.
Web devs are not the only kind of developer out there.
Web devs are not the only kind of developer out there.
Any competent dev will be functional in Dart in days. Flutter really is fantastic, I like being in Dart 90% of the time, no XML, no Storyboard. Currently employed on a Flutter project, hopefully jobs aspects improve.
I was part of a team who had to do two upgrades of the react native version. and every time, it was a pain taking weeks of developer productivity away.
...
i wonder if React Native fixed this problem... but their track record is not the best...
The 0.6 release brought in autolinking and a better integration with Cocoapods so worth checking out.
I think React Native had hot reloading before. At least the ClojureScript + React Native stuff did.
Hardly impressed with hot reloading, having done GUIs in Lisp, Smalltalk and Oberon.
Plus the competition is stepping up, with Swift UI, Xamarin, Jetpack Compose hot reload support.
Plus the competition is stepping up, with Swift UI, Xamarin, Jetpack Compose hot reload support.
It's one thing to have hot reload and another to have it also preserve the whole app state like Dart/Flutter does.
You mean like Common Lisp and Smalltalk do.
What's impressive is that they brought this experience to cross platform mobile. Reminds me of Guy Steele's quote about Java bringing the mainstream halfway to lisp but people could only complain.
It is so impressive that now other platforms are adding it, thus proving the point that Dart is not a special snowflake.
What Java brought, we already had in the form of Eiffel, Oberon, Modula-3, Smalltalk, Component Pascal, Dylan, they just suffered from not having Sun's budget offering a compiler and training materials for free.
Now they are trying to bolt into Java, features that some of those languages already had, but Java 1.0 ditched them like value types, AOT compilation to native code and proper generics.
I am betting that Dart will never have any relevant market share besides being the Flutter's language.
Android team is betting on Kotlin/Native and Jetpack Composer, so lets see who will win the internal politics.
What Java brought, we already had in the form of Eiffel, Oberon, Modula-3, Smalltalk, Component Pascal, Dylan, they just suffered from not having Sun's budget offering a compiler and training materials for free.
Now they are trying to bolt into Java, features that some of those languages already had, but Java 1.0 ditched them like value types, AOT compilation to native code and proper generics.
I am betting that Dart will never have any relevant market share besides being the Flutter's language.
Android team is betting on Kotlin/Native and Jetpack Composer, so lets see who will win the internal politics.
ouch
The Android code indeed looks like a copy paste of bad stack overflow answers.
I can't really hold it against the author .. learning several platforms at the same time is a bit much.
I can't really hold it against the author .. learning several platforms at the same time is a bit much.
Could you elaborate, or do you know of a better example of an idiomatic kotlin Android app?
sure.
Again, I want to stress out that this is not an attack against the author.
I started learning Android roughly 10 years ago now. I actually anecdotally recently started teaching it to my SO and it finding the right approach to do so was a challenge. The sources I use to keep up with the latest tech are not the ones you want to push to a beginner.
> know of a better example of an idiomatic kotlin Android app?
off the top of my head, I am not sure what open source app I would direct somebody to. There is always https://github.com/google/iosched . The big downside is that for very long they shied away from using some common libs like rx or dagger in order to show off what you can do with just the base google libs. I know that they have revised their approach but to be honest I haven't checked out the code source of this app in 2 years (they always do a big refresh around io)
Android is also in a spot that must feel like a catch 22 for its maintainers : the platform has for very long had an approach where very little was irrevocably decided for you by Google. Which was great since it allowed to use whatever pattern works best for your usecase but also means that this freedom can be very intimidating for newcomers. This has changed in the past 1 or 2 years from 2 different reasons :
- initiatives like jetpack provide an opinionated way of doing things on Android.
- we can't have nice things. Some APIs are progressively closed off. In some cases it is because of performances (since devs are too often not going to care a lot if they have a rogue foreground service siphoning the user battery as long as their feature works), security or privacy.
Looking at `createTableRows()`
Removing all the views before adding them again is extremely unidiomatic. As well as handling all your layouting in kotlin/java instead of xml.
A clean way to handle what op is doing would be first to define a ViewState : a model representing the UI. In itself, it is nothing fancy, just an immutable kotlin data class looking something like this :
data class IngredientsModel( val title : CharSequence, // "ingredients" val ingredients : List<IngredientModel> )
data class IngredientModel( val name : CharSequence, val text : CharSequence )
next up would be to apply it to the UI
a simple method like bind (model:IngredientsModel) should be in charge of that.
Using a previously inflated xml layout for the whole screen
And a RecyclerView (abstraction similar to iOS UICollectionView ) to display the ingredients
stuff like
tv1.setPadding(32, 6, 6, 6) -> padding applied manually instead of being done through a layout definition and moreover using raw pixel values instead of dp ones.
if (index >= cocktail!!.measurements.count()) -> you don't do this kind of logic in the view layer, ever. This is why I have defined an IngredientModel, so that what to display can be defined in the business logic, not in the view layer.
Reading the article "create layouts declaratively like with Dart,wasn’t around when I created this project"; it looks like the author tried very hard to write idiomatic flutter code (and not necessarily good one) in place of Android one.
Again, I want to stress out that this is not an attack against the author.
I started learning Android roughly 10 years ago now. I actually anecdotally recently started teaching it to my SO and it finding the right approach to do so was a challenge. The sources I use to keep up with the latest tech are not the ones you want to push to a beginner.
> know of a better example of an idiomatic kotlin Android app?
off the top of my head, I am not sure what open source app I would direct somebody to. There is always https://github.com/google/iosched . The big downside is that for very long they shied away from using some common libs like rx or dagger in order to show off what you can do with just the base google libs. I know that they have revised their approach but to be honest I haven't checked out the code source of this app in 2 years (they always do a big refresh around io)
Android is also in a spot that must feel like a catch 22 for its maintainers : the platform has for very long had an approach where very little was irrevocably decided for you by Google. Which was great since it allowed to use whatever pattern works best for your usecase but also means that this freedom can be very intimidating for newcomers. This has changed in the past 1 or 2 years from 2 different reasons :
- initiatives like jetpack provide an opinionated way of doing things on Android.
- we can't have nice things. Some APIs are progressively closed off. In some cases it is because of performances (since devs are too often not going to care a lot if they have a rogue foreground service siphoning the user battery as long as their feature works), security or privacy.
Looking at `createTableRows()`
Removing all the views before adding them again is extremely unidiomatic. As well as handling all your layouting in kotlin/java instead of xml.
A clean way to handle what op is doing would be first to define a ViewState : a model representing the UI. In itself, it is nothing fancy, just an immutable kotlin data class looking something like this :
data class IngredientsModel( val title : CharSequence, // "ingredients" val ingredients : List<IngredientModel> )
data class IngredientModel( val name : CharSequence, val text : CharSequence )
next up would be to apply it to the UI
a simple method like bind (model:IngredientsModel) should be in charge of that.
Using a previously inflated xml layout for the whole screen
And a RecyclerView (abstraction similar to iOS UICollectionView ) to display the ingredients
stuff like
tv1.setPadding(32, 6, 6, 6) -> padding applied manually instead of being done through a layout definition and moreover using raw pixel values instead of dp ones.
if (index >= cocktail!!.measurements.count()) -> you don't do this kind of logic in the view layer, ever. This is why I have defined an IngredientModel, so that what to display can be defined in the business logic, not in the view layer.
Reading the article "create layouts declaratively like with Dart,wasn’t around when I created this project"; it looks like the author tried very hard to write idiomatic flutter code (and not necessarily good one) in place of Android one.
It's a pity both Jetpack and SwiftUI / Combine weren't available / release worthy enough at the time of writing. Not sure about Android but a lot of the problems on the native iOS side would be fixed with that. The only difference is the cell reuse, which can be a real head scratcher indeed for a starting developer. It's definitely a part where you will find the performance vs ease of use decisions of early iOS. Got to say I often work around it by creating new ViewControllers and adding/replacing them every time a cell gets (re)used but this might not always work in places where performance is still a constraint.
I love SwiftUI, rewrote my side project in it and hope it takes off. That being said I don't think it's anywhere near ready for mainstream use and therefore wouldn't be particuly helpful in a comparison like this. The requirement of iOS13 alone means it's a non-starter for a lot of business cases.
Well if iOS 13 adoption keeps growing like this I think any project released mid 2020 could use it - unless every % of missed users really means a lot of missed income.
The buttons floating at the right side are really annoying.
Would be interested to see a comparison with QtQuick as it uses the same model than Flutter - reimplement everything and render it on the GPU (but with an additional decade's worth of optimizations)
I'm really interested in learning Flutter for future app development as I could really use the time saved in development. But, one thing which really concerns me is the volatility of Google w.r.t products which doesn't get enough adoption i.e. in other words 'I'm afraid Google will kill Flutter'.
[deleted]
I know this happened with Angular 1, but I am curious why I never hear this sentiment for GoLang which people seem nuts for. Is it because Google is responsible for maintaining the actual UI Widgets in this case?
I use GoLang regularly and so consider this my personal opinion for your question;
•GoLang filled up a need gap of simple yet high performant server side language which could scale up with the developments in the compute power.
•By the time GoLang stable release was made, it was widely used by Google itself within its production infrastructure. Docker, Kubernetes, Youtube using Go was a huge confidence booster.
•Of course it's been a decade since release, so it has stood the test of time even though there are criticisms regarding language design and Google's oversight on language development; even though major development comes from Google, I don't think there is a chance that they will pull it off just because they are heavily invested in it.
As for Flutter,
• It's been just two years, so we cannot compare it directly with current GoLang reg adoption and also this is a framework. I think Flutter didn't really fill any need gap Google had, it just seems like they waited to see if Cross-platform app development would still be a thing by the end of the decade and rushed in with a framework to compete with Xamarin/React Native.
• Google already has two first level language support for its android development Java, Kotlin but Flutter requires one to use Dart which wasn't originally created to be used in such a framework. So both android and iOS developers need to learn another language to build cross-platform apps using Flutter.
• Google claims it uses Flutter for some part of Google Assistant for Google Home devices and it is expected that Fuchsia uses Flutter as primary development framework; that's all in the future, if Google wants to inspire confidence they need to release a major app written using Flutter for android/iOS.
In short, I don't see Google loosing much in stopping development on Flutter as much as it stands to loose if stops development on GoLang and lately that's how Google has treated its projects. Of-course both are open-source, may be if Google stopped development on Flutter, the UI-widgets can still be developed by the community but I doubt whether the core-framework can be developed by just the community.
•GoLang filled up a need gap of simple yet high performant server side language which could scale up with the developments in the compute power.
•By the time GoLang stable release was made, it was widely used by Google itself within its production infrastructure. Docker, Kubernetes, Youtube using Go was a huge confidence booster.
•Of course it's been a decade since release, so it has stood the test of time even though there are criticisms regarding language design and Google's oversight on language development; even though major development comes from Google, I don't think there is a chance that they will pull it off just because they are heavily invested in it.
As for Flutter,
• It's been just two years, so we cannot compare it directly with current GoLang reg adoption and also this is a framework. I think Flutter didn't really fill any need gap Google had, it just seems like they waited to see if Cross-platform app development would still be a thing by the end of the decade and rushed in with a framework to compete with Xamarin/React Native.
• Google already has two first level language support for its android development Java, Kotlin but Flutter requires one to use Dart which wasn't originally created to be used in such a framework. So both android and iOS developers need to learn another language to build cross-platform apps using Flutter.
• Google claims it uses Flutter for some part of Google Assistant for Google Home devices and it is expected that Fuchsia uses Flutter as primary development framework; that's all in the future, if Google wants to inspire confidence they need to release a major app written using Flutter for android/iOS.
In short, I don't see Google loosing much in stopping development on Flutter as much as it stands to loose if stops development on GoLang and lately that's how Google has treated its projects. Of-course both are open-source, may be if Google stopped development on Flutter, the UI-widgets can still be developed by the community but I doubt whether the core-framework can be developed by just the community.
The sad but true reason is because people aren't generally making rational decisions on here. They'll claim a reason, but it's usually really based on pre-conceived notions. "Google kills projects so I won't use Flutter, but will definitely go all in on GoLang" is a great example of this.
Ultimately it’s hard to evaluate using a single simplistic app. It’s not a matter of setting up a better evaluation but rather real life.
A different way to look at this is adoption, and flutter isn’t at all popular. I don’t believe that’s only a matter of visibility.
React Native is the 5th and Xamarin is the 7th most used frameworks for iOS while flutter is 15th, and similarly among Android apps where it’s 10th.
Source: https://appfigures.com/top-sdks/development/all
* Requires a free account to see beyond the top 5 results.
We just recently shipped an Android app built with react native and while we ran into a variety of challenges to keep the UI smooth the rest was very easy. If flutter was as easy I’d imagine it’d see more adoption.
A different way to look at this is adoption, and flutter isn’t at all popular. I don’t believe that’s only a matter of visibility.
React Native is the 5th and Xamarin is the 7th most used frameworks for iOS while flutter is 15th, and similarly among Android apps where it’s 10th.
Source: https://appfigures.com/top-sdks/development/all
* Requires a free account to see beyond the top 5 results.
We just recently shipped an Android app built with react native and while we ran into a variety of challenges to keep the UI smooth the rest was very easy. If flutter was as easy I’d imagine it’d see more adoption.
By some measures Flutter is taking off [1], and it's Github repo has certainly drawn some interest [2]. At any rate, Flutter is far from unpopular, and is iirc the youngest of any of the competing frameworks.
[1] https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg...
[2] https://github.com/flutter/flutter
[1] https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg...
[2] https://github.com/flutter/flutter
It’s really interesting to see so much interest in flutter is coming from China. But keep in mind, that’s search traffic not apps using flutter.
Incremental growth means nothing. It's easy to double your mind share when you start with 0.0001%.
The bottom line is that Flutter has close to nonexistent adoption in the real world, not helped by the fact that Google doesn't really seem to care at all about it (at least the Android team has shown zero interest to support Flutter, which should be its death knell right there).
The bottom line is that Flutter has close to nonexistent adoption in the real world, not helped by the fact that Google doesn't really seem to care at all about it (at least the Android team has shown zero interest to support Flutter, which should be its death knell right there).
Flutter is trying to be Dart's Rails, and that is what will ultimately kill it, as the language is useless without Flutter.
Perhaps it comes down to personal preferences and there is no correct answer. I rewrote one of my apps in Flutter to test it; there were some things that were better, and some things much worse. I mean when React Native goes wrong on some build it's like 24 hours of trying to recompile and the pain is palpable.
Ultimately I decided against using flutter, personally. Dart is okay, actually I quite liked it, but the flutter syntax is verbose is a special way; when you effectively require your IDE to code for you that to my old bones is a certain type of code smell and something is fundamentally amiss.
I may have been doing it wrong, but centering and styling text didn't feel like it should be a widget for each single thing.
Ultimately I decided against using flutter, personally. Dart is okay, actually I quite liked it, but the flutter syntax is verbose is a special way; when you effectively require your IDE to code for you that to my old bones is a certain type of code smell and something is fundamentally amiss.
I may have been doing it wrong, but centering and styling text didn't feel like it should be a widget for each single thing.
That's some admirable persistence by the author... I gave up on Flutter (for now) right after installing, having to accept (and supposedly read first) about 10 licenses during the process and then failing to start basically the default app in the Android emulator with obscure error messages. What a terrible UX developers have to put up with these days... At least it was funny to let Android Studio analyze the code (the default app), yielding these:
FlutterBinaryMessenger.h
Typo: In word 'FLUTTERBINARYMESSENGER'
Typo: In word 'Implementated'
Typo: In word 'commuication'
That’s weird.. aside from accepting licenses (which to me is fine), Flutter has always been a buttery smooth development process for me—much more so that trying to wrangle Xcode or Android Studio.
So, you use Flutter from some other IDE and avoid Android Studio altogether? I'll probably try that next, I just did what flutter.io suggested and didn't have any other suitable IDE or editor set up for Dart etc.:
Flutter relies on a full installation of Android Studio to
supply its Android platform dependencies. However, you can
write your Flutter apps in a number of editors; a later
step will discuss that.
I had some similar initial issues getting it working (also suffered from the comedy issues with not being able to run Android Studio on modern JDK/JRE versions due to JavaFX stuff being removed).
After I'd faffed about and made it all work I must say that Flutter itself felt very nice. The hot-reload alone is enough to make you massively more productive. Dart is a perfectly reasonable language too, much nicer and better thought out than JavaScript, even with Typescript on top. Integers that are, for a start...
After I'd faffed about and made it all work I must say that Flutter itself felt very nice. The hot-reload alone is enough to make you massively more productive. Dart is a perfectly reasonable language too, much nicer and better thought out than JavaScript, even with Typescript on top. Integers that are, for a start...
This whole commentary will change in about 6 months when Jetpack Compose goes live.
Compose is basically android-native SwiftUi equivalent - a reacty way to write apps. Officially sanctioned and tuned by the core Android team
Compose is basically android-native SwiftUi equivalent - a reacty way to write apps. Officially sanctioned and tuned by the core Android team
And most likely a reaction from Android team to the continuous questions about what they think about Flutter during Android Q&A sessions.
Flutter is also cross platform, a big advantage. No matter how well the Jetpack Compose experience is going to be, it's still only Android.
Nope. That boat has already sailed. And kotlin will most likely supersede Flutter because of the tooling.
https://www.jetbrains.com/lp/mobilecrossplatform/
(That links points to Yandex , etc who are using it in production)
https://www.jetbrains.com/lp/mobilecrossplatform/
(That links points to Yandex , etc who are using it in production)
That's only business logic, you still have to entirely reimplement the UI layer for each platform. Cross platform business logic isn't the killer feature that cross platform Devs are looking for.
sure. but that's going live in a couple of months. EAP was in KotlinConf.
This is a very useful article (both parts), many thanks to the author.
Have people found Dart to be a useful programming language for purposes other than Flutter? Does it provide a benefit over existing languages for other kinds of tasks?
I like a lot of what Flutter offers for cross-platform development, but it's hard for me to justify the cost of learning a separate language just for one tool, versus (for example) React Native which uses a multipurpose language with a massive ecosystem of existing libraries and tooling.
I like a lot of what Flutter offers for cross-platform development, but it's hard for me to justify the cost of learning a separate language just for one tool, versus (for example) React Native which uses a multipurpose language with a massive ecosystem of existing libraries and tooling.
We've been using Dart for years on a successful web app, front-end, back-end, and tooling. It's simple to learn. We've had devs experienced in C++ contributing to the codebase in a couple of days without any prior exposure. It's a great general purpose language, and with recent addition of extension methods and NNBD coming soon, it's getting even better. Ecosystem isn't as extensive as JS world, but it's pretty good. (As someone else in this thread stated, I too dislike the required semicolons, but no biggie, and there's an issue to perhaps remove or make them optional, maybe it'll happen eventually)
Give the language tour a quick look: https://dart.dev/guides/language/language-tour
I've been using Dart since the start (~8 years ago), and follow language development very closely.
Let me know if you have any more questions.
Give the language tour a quick look: https://dart.dev/guides/language/language-tour
I've been using Dart since the start (~8 years ago), and follow language development very closely.
Let me know if you have any more questions.
I discovered Flutter recently and love it! I want to buy in all the way. Could you go more into your experiences, especially with backend and tooling? I'm pretty sold on it for web dev, as I spent a ton of time trying to get into react/react native and am ready to move one.
I guess my main concern is support for libraries. I don't recall seeing Dart libraries for most GCP/AWS services. And what about all of the bajillion clients and neat stuff that has already been written for say Python. I feel like it's a tough pill to swallow to say goodbye to that stuff.
There is a package for gcloud (and also googleapis), and we are closing in to generate AWS API client libraries from the API definition JSONs.
I personally use Dart for almost every task.
Frontend - Flutter for the UI (Android, iOS and Web) Backend REST Services - Pure Dart or Aqueduct.io for more complex apps Scripting on my PC Command Line Interfaces for different Tools Advent of Code solutions Blockchain stuff Chat bots ... much more
So why do I like Dart?
The default libraries are amazing - dart:convert, dart:io and more. The asynchronous language features like async, Future and Streams are the best ones I found in a language until now. The Dart and especially Flutter docs (just look at the animation curves section) as well as the official YouTube videos do a great job of teaching different subjects. The combination of dynamic and statically typed objects and variables works really well in most cases. The List and Map operators are really good and easy to use. Package management with pub works and is fast.
Disadvantages
The Ecosystem for non-mobile apps needs more libs.
Conclusion
Try Flutter and see if you like working with Dart, it's very easy to pick up.
Frontend - Flutter for the UI (Android, iOS and Web) Backend REST Services - Pure Dart or Aqueduct.io for more complex apps Scripting on my PC Command Line Interfaces for different Tools Advent of Code solutions Blockchain stuff Chat bots ... much more
So why do I like Dart?
The default libraries are amazing - dart:convert, dart:io and more. The asynchronous language features like async, Future and Streams are the best ones I found in a language until now. The Dart and especially Flutter docs (just look at the animation curves section) as well as the official YouTube videos do a great job of teaching different subjects. The combination of dynamic and statically typed objects and variables works really well in most cases. The List and Map operators are really good and easy to use. Package management with pub works and is fast.
Disadvantages
The Ecosystem for non-mobile apps needs more libs.
Conclusion
Try Flutter and see if you like working with Dart, it's very easy to pick up.
I really like Flutter, infact it's the first language I've been really excited about since Python back in college, but I worry about learning something like Aqueduct.io. I feel like the biggest con with Flutter is that there are not that many resources relative to React Native, i fear the server frameworks would be even worse.
Definitely gonna try flutter for web though--im ready to say goodbye to React completely.
Definitely gonna try flutter for web though--im ready to say goodbye to React completely.
I’m not a huge fan of Dart (too OOP for my tastes), but if you know JavaScript or Java it is really easy to pick up. The only thing I struggled with are the required semi colons!
I have spoken to people who have used it for backend code, though that is rare.
I have spoken to people who have used it for backend code, though that is rare.
Google uses it for web apps and the Dart team itself uses Dart for all their command line tools.
In the latest release they added support for creating standalone binaries. I haven't tried it but it sounds promising.
There is a good package manager and a decent selection of libraries. I haven't tried it out lately though.
In the latest release they added support for creating standalone binaries. I haven't tried it but it sounds promising.
There is a good package manager and a decent selection of libraries. I haven't tried it out lately though.
Learning the language is going to be like 3% of learning Flutter/Mobile development.
Apperantly, "Google builds many critical web apps using the Dart language, often with AngularDart." [1]
I have never heard this from anyone else though.
[1]https://dart.dev/web
I have never heard this from anyone else though.
[1]https://dart.dev/web
[deleted]
Would have been nice to benchmarck ionic, especially since it has react support.
I've been out of mobile development since about 2013. What's the adoption rate of things like Flutter, are a significant % of apps built with it these days?
Don't miss the link at the bottom of the article to CPU utilization numbers. tl;dr: Flutter and React Native are dramatically easier to develop for than native toolkits and Flutter CPU utilization is better than native toolkits. That... is not what I was expecting.
Flutter tries to offload as much as possible to the GPU I think. This means the CPU load will likely be lower but GPU usage will likely be higher. Depending on the device the app is running on, this can still make the Flutter application consume more power.
I'd be interested to see the performance comparison taking into account both CPU and GPU usage.
I'd be interested to see the performance comparison taking into account both CPU and GPU usage.
Flutter is what I call the game engine design, that happens to simulate mobile UI toolkits. It's a native c++ render and view layer, so it has the potential to be as performant as native iOS & Android code.
Yeah, I wouldn't expect that either. It's the only one not using native components as far as I know.
With native toolkits being around for so long, why do they still suck to build with?
Because they carry around 10+ versions of compatibility debt
Why can't they release breaking changes under a major release?
Because there are many, many angry people with existing codebases that they would break, and you would get something like the python 2 to 3 saga.
iOS already pushes way too many breaking changes with every major swift release. A real break would be too much. They do it incrementally via things like jetpack compose or swift UI.
iOS already pushes way too many breaking changes with every major swift release. A real break would be too much. They do it incrementally via things like jetpack compose or swift UI.
Interesting take on mobile dev frameworks but unfort. with some flaws:
- OP compared dev time but he is more experienced in Flutter, not expressive
- Xamarin Forms is included, not sure if anyone really uses it anymore
- Left out new Iconic React which allows 100% same codebase on all platforms
- OP didn't mention that Flutter has no production-ready web version or at least he could have looked into the beta
However, nice that he took the time to give some basic infos.
- OP compared dev time but he is more experienced in Flutter, not expressive
- Xamarin Forms is included, not sure if anyone really uses it anymore
- Left out new Iconic React which allows 100% same codebase on all platforms
- OP didn't mention that Flutter has no production-ready web version or at least he could have looked into the beta
However, nice that he took the time to give some basic infos.
Slight tangent but why is the bottom portion of this article covered with social media icons?
Hard to read and is distracting.
This performance analysis is not very useful. How taxing an app is on the CPU is not a user-visible metric, unlike, for example, the time it takes from tapping on an app to it being responsive. The taxing of the CPU is only valuable to think about when thinking when analyzing battery impact (and it takes a lot more analysis than what was given). I’d be much more interested to see:
- startup time
- time to transition between screens (and ideally with more views on each screen, eg make two copies of each view)
- differences in network performance, if any
- startup time
- time to transition between screens (and ideally with more views on each screen, eg make two copies of each view)
- differences in network performance, if any
just learn WebAssembly, it's the future :o
It's not a matter of "just learn WebAssembly", nobody (with some exceptions to those working on tooling) is going to learn raw WebAssembly, it just won't happen.
I would suggest that Blazor (C#) and Yew (Rust) are probably two of the most usable frameworks currently. There are some commercial libraries for Blazor and even some open source, but more is needed. There are ongoing and breaking changes that will be painful if you start adopting now.
Beyond all of this, is the fact that you still are interacting with the DOM via a transport layer that will generally not be great for a lot of use cases, you might do well with a canvas and animation frame events, but that won't have good accessibility.
Even then we're talking about native applications for portable devices, which likely won't see a good WASM story for a few years and in the case of Apple, if ever.
I'm not saying that WASM isn't cool... it really is, and you can do some very cool things with it as a target both browser and in dedicated runtimes... it's just not ready/baked for application targets (yet), and you shouldn't be betting a startup, or long-lived application on it just yet.
I would suggest that Blazor (C#) and Yew (Rust) are probably two of the most usable frameworks currently. There are some commercial libraries for Blazor and even some open source, but more is needed. There are ongoing and breaking changes that will be painful if you start adopting now.
Beyond all of this, is the fact that you still are interacting with the DOM via a transport layer that will generally not be great for a lot of use cases, you might do well with a canvas and animation frame events, but that won't have good accessibility.
Even then we're talking about native applications for portable devices, which likely won't see a good WASM story for a few years and in the case of Apple, if ever.
I'm not saying that WASM isn't cool... it really is, and you can do some very cool things with it as a target both browser and in dedicated runtimes... it's just not ready/baked for application targets (yet), and you shouldn't be betting a startup, or long-lived application on it just yet.
Considering that the lifespan of a Google product is 4 years, would you really invest the time to become an expert on Flutter? Right now about 190 Google products are slated for retirement. They are even going to start killing the Google Cloud after 2023. It's a YUUGE bet.
Also, do you really want to invest time into learning Dart?
If you’re a small startup, just like we are doing at ours [1], you want to share as much code as possible between your web and mobile apps, and also backend, so sadly due to Dart, I don’t see us anywhere in the future using Flutter.
[1] https://standups.io
[1] https://standups.io
> you want to share as much code as possible between your web and mobile apps, and also backend
I've worked on 3 start-ups and 3 major, large companies. So far every single one of them tried to do the whole share code everywhere thing and every single time it ultimately cost us far, far more time to get everything working and then subsequently testing re-used code.
I've worked two projects where we used different components and code, for 99% of everything, across server, mobile and native and we were able to work _significantly_ faster.
So I'm curious, would you work towards sharing code again if you had to start from scratch? Has it ended up being worth it? Because my personal experience so far has seen it usually be more of a liability than anything else so I'd love to know how it worked out for others.
I've worked on 3 start-ups and 3 major, large companies. So far every single one of them tried to do the whole share code everywhere thing and every single time it ultimately cost us far, far more time to get everything working and then subsequently testing re-used code.
I've worked two projects where we used different components and code, for 99% of everything, across server, mobile and native and we were able to work _significantly_ faster.
So I'm curious, would you work towards sharing code again if you had to start from scratch? Has it ended up being worth it? Because my personal experience so far has seen it usually be more of a liability than anything else so I'd love to know how it worked out for others.
Not sure what you mean. Small startup here and we share code between frontend and backend just fine, using Dart.
What are you using for web? We're using react, and are planning to move to react-native-web for better web + mobile code sharing, and for Catalyst for having a native macOS app — not sure also if Flutter will work for that.
But it's key for us, since we started with JS, to stay in JS due to the knowledge out there and within our team — already. It, of course, depends on your team and in your hiring options.
I feel Flutter/Dart is still too immature to be deployed all across the stack. Maybe if you're today starting from scratch it would be doable, like it is for you. Mind sharing your landing page? I'm interested in seeing your product.
But it's key for us, since we started with JS, to stay in JS due to the knowledge out there and within our team — already. It, of course, depends on your team and in your hiring options.
I feel Flutter/Dart is still too immature to be deployed all across the stack. Maybe if you're today starting from scratch it would be doable, like it is for you. Mind sharing your landing page? I'm interested in seeing your product.
I built a web prototype in Flutter. I started in May and was using a web specific branch then Flutter's master branch. Doesn't run well (and I haven't optimized anything) but I am on stable now and its getting better.
Sent you an email with a link to it.
Sent you an email with a link to it.
Sure! Send it over to [email protected] :) Cheers!
Dart on the web frontend too, since start of the project. If you already had a substantial part of the project in JS, then Typescript would prob be better choice.
Dart is pretty mature at this point, with a very solid type system and getting better with extension methods just added and NNBD coming soon. It doesn't have as many packages, but it's pretty good.
> native macOS app — not sure also if Flutter will work for that.
They're working on flutter for desktop and there's a prototype.
Dart is pretty mature at this point, with a very solid type system and getting better with extension methods just added and NNBD coming soon. It doesn't have as many packages, but it's pretty good.
> native macOS app — not sure also if Flutter will work for that.
They're working on flutter for desktop and there's a prototype.
To me "not enough packages" out there means it's an instant competitive disadvantage to do production-ready apps, at least for Web — which at for us at Standups is a critical platform, especially given we're B2B.
Hopefully, it catches up soon though, as I do think Flutter is better than React Native in most fronts.
Hopefully, it catches up soon though, as I do think Flutter is better than React Native in most fronts.
Tough call though, since # of packages is a poor metric.
You can extract the non-Flutter parts to a seperate Dart package and compile it to JavaScript to share between both web and Flutter itself
Can you really straight up share components between react and react-native? Most of the RN components kinda map to mobile stuff--they're called things like View and TextInput. Most of what I see in React are divs with different stylings.
Moreover, can you share any code at all between node.js and react/RN?
Moreover, can you share any code at all between node.js and react/RN?
We did that in one of our projects using react-native-web https://github.com/necolas/react-native-web which basically allows you to write your web code within the react native project so everything is shared between web and mobile including the same views which are exported for the web with proper styling as mobile. Plus it allows you to override any components for your web using .web.js just as .ios.js and .android.js extentions.
Funny how this got many upvotes and then lots of downvotes through the hours.
I state again here: full stack Flutter is not ready for prime time. It needs more time to mature, and for small product startups I will not recommend it, not even if you’re starting from scratch.
I state again here: full stack Flutter is not ready for prime time. It needs more time to mature, and for small product startups I will not recommend it, not even if you’re starting from scratch.
> Creating the Flutter application only took approximately ⅓ of the time it took to create both native applications combined. This proves how much time you save by using cross-platform frameworks
No, it absolutely doesn't.
This is like saying "Writing 'hello world' in Python took three times less time than writing it in C, therefore Python is three times more productive than C".
If that's what the author of the article genuinely believes, then they are clearly not qualified to comment about language productivity.
No, it absolutely doesn't.
This is like saying "Writing 'hello world' in Python took three times less time than writing it in C, therefore Python is three times more productive than C".
If that's what the author of the article genuinely believes, then they are clearly not qualified to comment about language productivity.
X vs Y thing is always fun to read. We would all agree that Native apps are still better than RN and Flutter ones. So choosing either platform is a decision you need to take whether you want something fast and compromise on few thinks like look and performance or you want something solid. Secondly the issue with flutter is Dart. If you're a startup with 3 guys, working on Go lang for backend APIs, React / Svelte for frontend would you rather choose Js / TS for your app development or Dart. The whole time taken to build X using Y goes for a toss here. I would rather keep minimum moving parts if I'm small. If you're an enterprise and you've got resources you can experiment with Flutter + Dart, work for 2 years and when the project gets shelved ( just like other Google projects ) start migrating to Native or Js. After that you'll question yourself why did I learn Dart in the first place ? Did Flutter provide enough features that React Native didn't, etc.
Flutter isn’t going to get shelved. It is the UI framework for Fuchsia. I agree Dart is its biggest problem but Fuchsia prides itself on not having a single system language so I’m sure you’ll be able to target the flutter framework from kotlin and swift and rust and go soon. Also Dart isn’t hard.
TBH skimming the dart language, the only thing that was holding me back was the lack of optional types, and with dart 2.7 it looks like they've added it:
https://medium.com/dartlang/dart-2-7-a3710ec54e97
https://medium.com/dartlang/dart-2-7-a3710ec54e97
Fuchsia's future is still uncertain, and nowadays they also have C++ and Rust based UIs on the public repo.
Flutter is just a cheap Google copy of React just like now shelved Google Plus was a cheap Google copy of LinkedIn/Facebook. It can and will be discontinued.
It’s not cheap at all. It does things the right way. It’s the closest thing UI engineers have to a “write once”, deploy everywhere framework. Try it out if you haven’t. It’s definitely not cheap.
> Flutter isn’t going to get shelved.
That confident endorsement of future Flutter support is borderline misinformation.
Alphabet literally voted on shelving GCP ("the cloud business") a short time ago; https://www.cnbc.com/2019/12/17/google-reportedly-wants-to-b...
Dropping public Flutter support is a higher probability event.
That confident endorsement of future Flutter support is borderline misinformation.
Alphabet literally voted on shelving GCP ("the cloud business") a short time ago; https://www.cnbc.com/2019/12/17/google-reportedly-wants-to-b...
Dropping public Flutter support is a higher probability event.
I've never used Xamarind or flutter, but easily one of the best parts of using Expo (React-Native) was their built-in certificate management, guidance through the submission process, and eventually immediate publication of updates through running `expo publish`
My client was pleasantly speechless when I was able to change code and have it appear on her device a few seconds later, as it had been her experience that updates have to go through another review process.