17 ms·

Flutter vs. Other Mobile Development Frameworks: A UI and Performance Experiment

370 points by Rubytron 7y ago

jasondclinton 7y ago
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.
- pspeter3 7y ago
  Yeah, I wouldn't expect that either. It's the only one not using native components as far as I know.
- hanniabu 7y ago
  With native toolkits being around for so long, why do they still suck to build with?
  - anaisbetts 7y ago
    Because they carry around 10+ versions of compatibility debt
    - hanniabu 7y ago
      Why can't they release breaking changes under a major release?
      - novok 7y ago
        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.
- jeroenhd 7y ago
  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.
- novok 7y ago
  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.
arciini 7y ago
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 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
- bweitzman 7y ago
  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.builder.html 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-class.html 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.
Townley 7y ago
Another factor when evaluating platforms to build an app with includes ease of initial submission/submission of updates. 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.
- deltron3030 7y ago
  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..
  - Townley 7y ago
    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.
    - kangaroozach 7y ago
      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.
      - nl 7y ago
The_rationalist 7y ago
Would have been nice to benchmarck ionic, especially since it has react support.
huangc10 7y ago
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...
- amimetic 7y ago
  But a lot harder to address (probably effectively impossible). This is actually one of the best comparisons I’ve seen.
- zaphirplane 7y ago
  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.
thorum 7y ago
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.
- amimetic 7y ago
  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.
- alamaslah 7y ago
  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 https://dart.dev/web
- markdog12 7y ago
  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 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.
  - dickjocke 7y ago
    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.
brobot182 7y ago
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
Rochus 7y ago
This is a very useful article (both parts), many thanks to the author.
on_and_off 7y ago
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.
- e12e 7y ago
  Could you elaborate, or do you know of a better example of an idiomatic kotlin Android app?
  - on_and_off 7y ago
    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 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.
yuchi 7y ago
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.
- latchkey 7y ago
  Hyper Text Markup Language If JSX isn't a language, then what is HTML?
- crucialfelix 7y ago
  JSX aka JavaScript XML. It is technically a language.
  - yuchi 7y ago
    It’s an extension to a language. Would you call generics a language? Is TSX a different language from TypeScript?
betoharres 7y ago
just learn WebAssembly, it's the future :o
- tracker1 7y ago
  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.
babesh 7y ago
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?
sandov 7y ago
The buttons floating at the right side are really annoying.
jrs95 7y ago
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.
- dickjocke 7y ago
  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.
  - jrs95 7y ago
    Exactly what I was hoping to hear, I'll get started with it this weekend :)
    - dickjocke 7y ago
      Did you do it?
  - 7y ago
sleepinseattle 7y ago
Measure power consumption and framerate (especially for scrolling scenarios) rather than CPU usage before making any performance claims for mobile.
- CraftThatBlock 7y ago
  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
  - bsaul 7y ago
    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..
    - on_and_off 7y ago
      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.
    - dogprez 7y ago
      This might be worth checking out: https://flutter.dev/showcase https://flutter.dev/showcase Also this if you want to dig deeper: https://flutter-dashboard.appspot.com/benchmarks.html https://flutter-dashboard.appspot.com/benchmarks.html
braindongle 7y ago
<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>
- siquick 7y ago
  > 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.
  - dickjocke 7y ago
    <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.
    - pjmlp 7y ago
      Xamarin and Qt also give me the same, with more useful industry programming languages.
      - distances 7y ago
        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.
jpincheira 7y ago
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 https://standups.io
- markdog12 7y ago
  Not sure what you mean. Small startup here and we share code between frontend and backend just fine, using Dart.
  - jpincheira 7y ago
    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.
    - ipodopt 7y ago
      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.
      - jpincheira 7y ago
        Sure! Send it over to jp@standups.io :) Cheers!
    - markdog12 7y ago
      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.
eerrt 7y ago
Was hoping to see a comparison with https://www.nativescript.org/ https://www.nativescript.org/
- hardwaresofton 7y ago
  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.
  - csscrack 7y ago
    Didn't know about Nativescript. Did you try it already?
    - hardwaresofton 7y ago
      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/ https://nativescript-vue.org/ [1]: https://svelte-native.technology/ https://svelte-native.technology/
      - FlyingSnake 7y ago
        How's the development experience? Can you debug/step-in to the code?
Benjammer 7y ago
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.
- crowbahr 7y ago
  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.
  - Abishek_Muthian 7y ago
    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.
  - ink404 7y ago
    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)
latchkey 7y ago
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 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.
- rhlsthrm 7y ago
  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.
- verttii 7y ago
  Wow this looks interesting, I don't know why it has slipped right past me so far.
- cgs 7y ago
  I was glad I found Provider after almost diving into BLoC. The less boilerplate and context switching the better.
deleted 7y ago
[deleted]
Abishek_Muthian 7y ago
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 7y ago
  [deleted]
- tessting 7y ago
  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?
  - Abishek_Muthian 7y ago
    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.
arielm 7y ago
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 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.
- virtualwhys 7y ago
  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,react%20native,%2Fm%2F0gtv959,%2Fg%2F1q6l_n0n0 https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg... [2] https://github.com/flutter/flutter https://github.com/flutter/flutter
  - arielm 7y ago
    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.
  - hota_mazi 7y ago
    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).
- pjmlp 7y ago
  Flutter is trying to be Dart's Rails, and that is what will ultimately kill it, as the language is useless without Flutter.
shubham_sinha 7y ago
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.
- dcow 7y ago
  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.
  - novok 7y ago
    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
  - Supermancho 7y ago
    > 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-be-top-two-player-in-cloud-by-2023.html https://www.cnbc.com/2019/12/17/google-reportedly-wants-to-b... Dropping public Flutter support is a higher probability event.
  - 7y ago
mindfulplay 7y ago
Slight tangent but why is the bottom portion of this article covered with social media icons? Hard to read and is distracting.
blarnopre 7y ago
"This year I graduated" Stopped reading there. Work in the industry a minute and then your opinion will carry weight.
papito 7y ago
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.
- throwno 7y ago
  Also, do you really want to invest time into learning Dart?
  - agumonkey 7y ago
    I don't trust dart to exist long, but some ideas in it were worth reading about
  - verttii 7y ago
    It takes like a few days to pick up and you can easily be productive from day 1. Dart's been around for some 8 years already, I'd assume Flutter bites the dust sooner than Dart will.
lazyjones 7y ago
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' Doesn't look like people actually use all these features much.
- hamaluik 7y ago
  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.
  - lazyjones 7y ago
    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. Is the general consensus that IntelliJ-based Android Studio isn't really a good choice as IDE?
    - dragonfax 7y ago
      I used flutter from Android Studio and from VSCode, and neither ever gave me any gruff.
    - hamaluik 7y ago
      I use visual studio code, it’s the editor I’m most comfortable with these days. I have android studio installed but don’t really use it except when publishing.
hota_mazi 7y ago
> 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.
cauchyk 7y ago
A lot of the power that flutter has comes from hot-reload. Dart + JIT powers this. I noticed that SwiftUI does this too. I wonder if SwiftUI composits and paints onto an underlying CALayer just like flutter does.
- novok 7y ago
  Swift UI hot reload i'm guessing is less flexible than flutter's
sandGorgon 7y ago
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
- pjmlp 7y ago
  And most likely a reaction from Android team to the continuous questions about what they think about Flutter during Android Q&A sessions.
- yuvalr1 7y ago
  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.
  - sandGorgon 7y ago
    Nope. That boat has already sailed. And kotlin will most likely supersede Flutter because of the tooling. https://www.jetbrains.com/lp/mobilecrossplatform/ https://www.jetbrains.com/lp/mobilecrossplatform/ (That links points to Yandex , etc who are using it in production)
    - socceroos 7y ago
      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.
      - sandGorgon 7y ago
        sure. but that's going live in a couple of months. EAP was in KotlinConf.
csscrack 7y ago
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.
novok 7y ago
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.
- afro88 7y ago
  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..
wiradikusuma 7y ago
"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.
jcelerier 7y ago
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)
dep_b 7y ago
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.
- jamil7 7y ago
  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.
  - dep_b 7y ago
    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.
xwowsersx 7y ago
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?
ajdegol 7y ago
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.

370 points by Rubytron 7y ago

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.

pspeter3 7y ago
Yeah, I wouldn't expect that either. It's the only one not using native components as far as I know.
hanniabu 7y ago
With native toolkits being around for so long, why do they still suck to build with?
- anaisbetts 7y ago
  Because they carry around 10+ versions of compatibility debt
  - hanniabu 7y ago
    Why can't they release breaking changes under a major release?
    - novok 7y ago
      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.
jeroenhd 7y ago
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.
novok 7y ago
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.

arciini 7y ago

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 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

bweitzman 7y ago
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.builder.html 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-class.html 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.

Townley 7y ago

Another factor when evaluating platforms to build an app with includes ease of initial submission/submission of updates. 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.

deltron3030 7y ago
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..
- Townley 7y ago
  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.
  - kangaroozach 7y ago
    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.
    - nl 7y ago

The_rationalist 7y ago

Would have been nice to benchmarck ionic, especially since it has react support.

huangc10 7y ago

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...

amimetic 7y ago
But a lot harder to address (probably effectively impossible). This is actually one of the best comparisons I’ve seen.
zaphirplane 7y ago
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.

thorum 7y ago

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.

amimetic 7y ago
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.
alamaslah 7y ago
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 https://dart.dev/web
markdog12 7y ago
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 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.
- dickjocke 7y ago
  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.

brobot182 7y ago

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

Rochus 7y ago

This is a very useful article (both parts), many thanks to the author.

on_and_off 7y ago

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.

e12e 7y ago
Could you elaborate, or do you know of a better example of an idiomatic kotlin Android app?
- on_and_off 7y ago
  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 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.

yuchi 7y ago

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.

latchkey 7y ago
Hyper Text Markup Language If JSX isn't a language, then what is HTML?
crucialfelix 7y ago
JSX aka JavaScript XML. It is technically a language.
- yuchi 7y ago
  It’s an extension to a language. Would you call generics a language? Is TSX a different language from TypeScript?

betoharres 7y ago

just learn WebAssembly, it's the future :o

tracker1 7y ago
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.

babesh 7y ago

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?

sandov 7y ago

The buttons floating at the right side are really annoying.

jrs95 7y ago

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.

dickjocke 7y ago
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.
- jrs95 7y ago
  Exactly what I was hoping to hear, I'll get started with it this weekend :)
  - dickjocke 7y ago
    Did you do it?
- 7y ago

sleepinseattle 7y ago

Measure power consumption and framerate (especially for scrolling scenarios) rather than CPU usage before making any performance claims for mobile.

CraftThatBlock 7y ago
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
- bsaul 7y ago
  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..
  - on_and_off 7y ago
    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.
  - dogprez 7y ago
    This might be worth checking out: https://flutter.dev/showcase https://flutter.dev/showcase Also this if you want to dig deeper: https://flutter-dashboard.appspot.com/benchmarks.html https://flutter-dashboard.appspot.com/benchmarks.html

braindongle 7y ago

<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>

siquick 7y ago
> 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.
- dickjocke 7y ago
  <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.
  - pjmlp 7y ago
    Xamarin and Qt also give me the same, with more useful industry programming languages.
    - distances 7y ago
      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.

jpincheira 7y ago

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 https://standups.io

markdog12 7y ago
Not sure what you mean. Small startup here and we share code between frontend and backend just fine, using Dart.
- jpincheira 7y ago
  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.
  - ipodopt 7y ago
    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.
    - jpincheira 7y ago
      Sure! Send it over to jp@standups.io :) Cheers!
  - markdog12 7y ago
    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.

eerrt 7y ago

Was hoping to see a comparison with https://www.nativescript.org/ https://www.nativescript.org/

hardwaresofton 7y ago
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.
- csscrack 7y ago
  Didn't know about Nativescript. Did you try it already?
  - hardwaresofton 7y ago
    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/ https://nativescript-vue.org/ [1]: https://svelte-native.technology/ https://svelte-native.technology/
    - FlyingSnake 7y ago
      How's the development experience? Can you debug/step-in to the code?

Benjammer 7y ago

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.

crowbahr 7y ago
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.
- Abishek_Muthian 7y ago
  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.
- ink404 7y ago
  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)

latchkey 7y ago

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 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.

rhlsthrm 7y ago
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.
verttii 7y ago
Wow this looks interesting, I don't know why it has slipped right past me so far.
cgs 7y ago
I was glad I found Provider after almost diving into BLoC. The less boilerplate and context switching the better.

deleted 7y ago

[deleted]

Abishek_Muthian 7y ago

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 7y ago
[deleted]
tessting 7y ago
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?
- Abishek_Muthian 7y ago
  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.

arielm 7y ago

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 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.

virtualwhys 7y ago
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,react%20native,%2Fm%2F0gtv959,%2Fg%2F1q6l_n0n0 https://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg... [2] https://github.com/flutter/flutter https://github.com/flutter/flutter
- arielm 7y ago
  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.
- hota_mazi 7y ago
  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).
pjmlp 7y ago
Flutter is trying to be Dart's Rails, and that is what will ultimately kill it, as the language is useless without Flutter.

shubham_sinha 7y ago

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.

dcow 7y ago
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.
- novok 7y ago
  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
- Supermancho 7y ago
  > 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-be-top-two-player-in-cloud-by-2023.html https://www.cnbc.com/2019/12/17/google-reportedly-wants-to-b... Dropping public Flutter support is a higher probability event.
- 7y ago

mindfulplay 7y ago

Slight tangent but why is the bottom portion of this article covered with social media icons? Hard to read and is distracting.

blarnopre 7y ago

"This year I graduated" Stopped reading there. Work in the industry a minute and then your opinion will carry weight.

papito 7y ago

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.

throwno 7y ago
Also, do you really want to invest time into learning Dart?
- agumonkey 7y ago
  I don't trust dart to exist long, but some ideas in it were worth reading about
- verttii 7y ago
  It takes like a few days to pick up and you can easily be productive from day 1. Dart's been around for some 8 years already, I'd assume Flutter bites the dust sooner than Dart will.

lazyjones 7y ago

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' Doesn't look like people actually use all these features much.

hamaluik 7y ago
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.
- lazyjones 7y ago
  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. Is the general consensus that IntelliJ-based Android Studio isn't really a good choice as IDE?
  - dragonfax 7y ago
    I used flutter from Android Studio and from VSCode, and neither ever gave me any gruff.
  - hamaluik 7y ago
    I use visual studio code, it’s the editor I’m most comfortable with these days. I have android studio installed but don’t really use it except when publishing.

hota_mazi 7y ago

> 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.

cauchyk 7y ago

A lot of the power that flutter has comes from hot-reload. Dart + JIT powers this. I noticed that SwiftUI does this too. I wonder if SwiftUI composits and paints onto an underlying CALayer just like flutter does.

novok 7y ago
Swift UI hot reload i'm guessing is less flexible than flutter's

sandGorgon 7y ago

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

pjmlp 7y ago
And most likely a reaction from Android team to the continuous questions about what they think about Flutter during Android Q&A sessions.
yuvalr1 7y ago
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.
- sandGorgon 7y ago
  Nope. That boat has already sailed. And kotlin will most likely supersede Flutter because of the tooling. https://www.jetbrains.com/lp/mobilecrossplatform/ https://www.jetbrains.com/lp/mobilecrossplatform/ (That links points to Yandex , etc who are using it in production)
  - socceroos 7y ago
    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.
    - sandGorgon 7y ago
      sure. but that's going live in a couple of months. EAP was in KotlinConf.

csscrack 7y ago

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.

novok 7y ago

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.

afro88 7y ago
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..

wiradikusuma 7y ago

"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.

jcelerier 7y ago

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)

dep_b 7y ago

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.

jamil7 7y ago
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.
- dep_b 7y ago
  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.

xwowsersx 7y ago

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?

ajdegol 7y ago

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.