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.
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 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.
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.
It's still a great write-up, but that part hurt me.
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.
This has the added benefit of being able to see the views without having to compile your code.
Also, in Flutter and React Native you don’t (typically) have to wait for your code to compile as they do hot reload.
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.
You get both with Android Native, layout preview and hot reloading.
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.
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 :/
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.
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
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.
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.
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 used Nativescript-Vue 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 -- 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.
Also, I'd honestly argue at you that development is so fast for Nativescript (especially when you start using Hot Module Replacement) 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, but my money is on Nativescript being better at it.
There's also the possibility of using vastly lighter weight frameworks, for example svelte-native which should be quite a bit more responsive.
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 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. 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.
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.
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, 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??
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?
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.
"Here" as in HN? Some of the comments on every Flutter post are people complaining about Dart, "why didn't you choose Kotlin," etc.
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.
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..
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.
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'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.
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.
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?
Also startup time is another interest to me, I've heard flutter apps tend to have slower startup times.
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..
Props to the author.
If JSX isn't a language, then what is HTML?
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:
- 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 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
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.
Also I'm not sure that Xamarain or QT are really very relevant, HNSVBubble or otherwise.
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.
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.
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.
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.
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?
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.
Not gonna happen, especially with Google’s track record. Already been burned by the Angular v1 -> v2+ nightmare.
Web devs are not the only kind of developer out there.
Plus the competition is stepping up, with Swift UI, Xamarin, Jetpack Compose hot reload support.
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.
I can't really hold it against the author .. learning several platforms at the same time is a bit much.
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
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.
•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.
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.
* 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.
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).
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.
Typo: In word 'FLUTTERBINARYMESSENGER'
Typo: In word 'Implementated'
Typo: In word 'commuication'
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.
Compose is basically android-native SwiftUi equivalent - a reacty way to write apps.
Officially sanctioned and tuned by the core Android team
(That links points to Yandex , etc who are using it in production)
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.
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.
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
... 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.
The Ecosystem for non-mobile apps needs more libs.
Try Flutter and see if you like working with Dart, it's very easy to pick up.
Definitely gonna try flutter for web though--im ready to say goodbye to React completely.
I have spoken to people who have used it for backend code, though that is rare.
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.
I have never heard this from anyone else though.
I'd be interested to see the performance comparison taking into account both CPU and GPU usage.
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.
- 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.
- 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
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'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.
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.
Sent you an email with a link to it.
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.
Hopefully, it catches up soon though, as I do think Flutter is better than React Native in most fronts.
Moreover, can you share any code at all between node.js and react/RN?
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.
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.
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.