Flutter and Dart, or how to quickly build a mobile app without losing your hair(altkomsoftware.pl)
altkomsoftware.pl
Flutter and Dart, or how to quickly build a mobile app without losing your hair
https://altkomsoftware.pl/blog/flutter-dart-quickly-build-mobile-app-without-losing-much-hair/
178 comments
Everyone from original Dart team left, Lars is now one of co-founders of a startup trying to sell a Dart like language for IoT.
Dart and Flutter futures are are now married, and I still don't buy into Flutter.
Languages married with UI frameworks seldom last, specially when the competition outside of the UI framework is so much better in tooling and available set of libraries.
Plus hot reloading were a novelty when Smalltalk, Common Lisp, Oberon System, Eiffel got introduced into the market.
And the competition isn't sleeping either, Flutter touched the Android team nerves hard enough that now we are getting Jetpack Composer, Xamarin already has its prototype available, Qt always kind of had it, so in the next twos (give or take it), all the cross-platform mobile frameworks will have dynamic code reload, with more market relevant languages, couple with 20 - 30 years of libraries.
Until Google releases Fuchsia and makes everyone write Dart code, I will pass. Qt, Xamarin, PWAs do the job just fine, with more mature languages.
Dart and Flutter futures are are now married, and I still don't buy into Flutter.
Languages married with UI frameworks seldom last, specially when the competition outside of the UI framework is so much better in tooling and available set of libraries.
Plus hot reloading were a novelty when Smalltalk, Common Lisp, Oberon System, Eiffel got introduced into the market.
And the competition isn't sleeping either, Flutter touched the Android team nerves hard enough that now we are getting Jetpack Composer, Xamarin already has its prototype available, Qt always kind of had it, so in the next twos (give or take it), all the cross-platform mobile frameworks will have dynamic code reload, with more market relevant languages, couple with 20 - 30 years of libraries.
Until Google releases Fuchsia and makes everyone write Dart code, I will pass. Qt, Xamarin, PWAs do the job just fine, with more mature languages.
Your post reads as FUD. Of course it isn't because I assume you are not one flutter's competitors. Nevertheless, worrying about what something might do in the future is classic FUD. We don't know if those others will develop hot reload, we don't know when and we don't know how good it will be. So FUD is a poor basis for a technical decision.
There's some merit in the mature language argument but dart has been around for some time now and doesn't have any radical features - although on the other hand you seem to be saying it's not novel enough like Oberon etc.
Do all those others have 20-30 years of libraries? I think that's just Qt. I spent a couple of years using Qt and it's very good but it is C++ which isn't for everyone. (The python version probably fails your maturity criteria)
There's some merit in the mature language argument but dart has been around for some time now and doesn't have any radical features - although on the other hand you seem to be saying it's not novel enough like Oberon etc.
Do all those others have 20-30 years of libraries? I think that's just Qt. I spent a couple of years using Qt and it's very good but it is C++ which isn't for everyone. (The python version probably fails your maturity criteria)
Yes they do, Java was released in 1996, .NET in 2002, JavaScript if we consider only npm release then 2010.
What FUD? Had not been for AdWords team there wouldn't be any Dart to talk about.
Right now, Dart is meaningless without Flutter.
While all the other languages are a safer bet, in terms of what to have on the CV, even if the frameworks written in them fail in the market.
What FUD? Had not been for AdWords team there wouldn't be any Dart to talk about.
Right now, Dart is meaningless without Flutter.
While all the other languages are a safer bet, in terms of what to have on the CV, even if the frameworks written in them fail in the market.
It’s good to have multiple choices, but given the momentum and quality of apps developed using Flutter, I think it’s ahead and will have enough developers to keep it relevant and stay.
Also UI programming is very complex given the proliferation of device form factors, interaction and implicit inputs using sensors. It needs language especially designed to handle all of it and provide a smooth user experience. For end user UI is the whole system. Dart is especially designed for it.
It provides superior developer experience compared to other cross platform UI toolkit. I think a language designed for user interface programming providing clean, smooth and performant developer experience is a need which dart fill.
Obviously not everyone likes declarative UI programming and they will lean towards what they know. I am from the camp who prefer declarative UI’s and that’s the reason like SwiftUI and Flutter.
Also UI programming is very complex given the proliferation of device form factors, interaction and implicit inputs using sensors. It needs language especially designed to handle all of it and provide a smooth user experience. For end user UI is the whole system. Dart is especially designed for it.
It provides superior developer experience compared to other cross platform UI toolkit. I think a language designed for user interface programming providing clean, smooth and performant developer experience is a need which dart fill.
Obviously not everyone likes declarative UI programming and they will lean towards what they know. I am from the camp who prefer declarative UI’s and that’s the reason like SwiftUI and Flutter.
Dart replacing JS would be an interesting timeline but not one we’re in for at least short term.
I also had concerns about Dart/Flutter at first but they almost entirely went away a week after starting.
It’s just really friendly. As far as Flutter is concerned it’s awesome you can see the Dart objects that build the Flutter widgets, the language itself is good and getting better, I’m just really happy we went this direction.
I also had concerns about Dart/Flutter at first but they almost entirely went away a week after starting.
It’s just really friendly. As far as Flutter is concerned it’s awesome you can see the Dart objects that build the Flutter widgets, the language itself is good and getting better, I’m just really happy we went this direction.
> Lara Bak
Lars Bak
> no one wants dartvm in browsers except chrome
The Chrome team also rejected the Dart VM
Lars Bak
> no one wants dartvm in browsers except chrome
The Chrome team also rejected the Dart VM
>It might fit Facebook’s case (although they abandoned it themselves in favour of native speaks volumes about it).
This doesn't appear to be true. Do you have a source?
This doesn't appear to be true. Do you have a source?
I’m not sure about abandoned but I think the uptake at facebook was never really that big, on iOS only the marketplace is written in RN with the rest remaining in ObjC / UIKit. This doesn’t really mean much though since theres no reason for them to rewrite everything in RN. I would be interested to know what the uptake is for new projects there.
>But I think keeping in sync changes in API, hardware device drivers and new interactions across different platforms and device will still be nightmare and in general it will play catch up with native. It can be seen in the number of issues opened on flutter project on GitHub [1]. Hopefully there is some support from different platforms so it remains reasonable choice and perform well compared to native.
I am an optimist; I have high hopes for the future of mobile development. Specifically, I hope that the developers who develop AndroidOS and iOS will metaphorically bend over backwards to make Flutter compatible with those operating systems. After all, isn't it in Apple and Google's best interest to make mobile development as painless as possible?
I am an optimist; I have high hopes for the future of mobile development. Specifically, I hope that the developers who develop AndroidOS and iOS will metaphorically bend over backwards to make Flutter compatible with those operating systems. After all, isn't it in Apple and Google's best interest to make mobile development as painless as possible?
It's in Apple's interest to make development for solely iOS as painless as possible. See Metal vs Vulkan.
Android exists so that Apple doesn't have 100% of the market share, not because Google cares about the UX of the users or the developers.
I think neither have any real incentive to make Flutter work better than it already does.
Android exists so that Apple doesn't have 100% of the market share, not because Google cares about the UX of the users or the developers.
I think neither have any real incentive to make Flutter work better than it already does.
A lot of apps are still developed iOS-first, which is a problem for Android. Encouraging cross-platform development over iOS-first is a win for the Android platform, not so much for Apple.
>A lot of apps are still developed iOS-first
Why? Last time I checked, Android had 85% of the market share.
Why? Last time I checked, Android had 85% of the market share.
Value of users = number of users * amount users spend
A chunk of Android's market share is people for whom $5 isn't a coffee but a days wages.
A chunk of Android's market share is people for whom $5 isn't a coffee but a days wages.
While probably true globally, that isn't so in every local.
My team develops and maintains a mobile banking application for a national market of a small European nation, and our user base is 70% Android. Due to wages here, 5$ is chump change.
Obviously though, we aren't monetizing our product in the usual way.
My team develops and maintains a mobile banking application for a national market of a small European nation, and our user base is 70% Android. Due to wages here, 5$ is chump change.
Obviously though, we aren't monetizing our product in the usual way.
> Obviously though, we aren't monetizing our product in the usual way.
I think that could be a large difference in approaches.
You are a bank and want all of your customers happy. If bank made an iOS only it would piss off a lot of its customers.
On the other hand if you are monetizing, you have to look at revenue streams from both platforms and decide which is the bigger revenue stream (not most users) and make sure that one work's first. Obviously you want both to work well but if the split is 70/30 to iOS you will prioritize iOS first.
I think that could be a large difference in approaches.
You are a bank and want all of your customers happy. If bank made an iOS only it would piss off a lot of its customers.
On the other hand if you are monetizing, you have to look at revenue streams from both platforms and decide which is the bigger revenue stream (not most users) and make sure that one work's first. Obviously you want both to work well but if the split is 70/30 to iOS you will prioritize iOS first.
Not to be pedantic, but I think you mean the opposite of chump change?
Also, I absolutely didn't mean to say it's impossible to monitize Android. I only meant to say it isn't clear Android is a significantly more rewarding to target customer base than iPhone, as my parent said.
Also, I absolutely didn't mean to say it's impossible to monitize Android. I only meant to say it isn't clear Android is a significantly more rewarding to target customer base than iPhone, as my parent said.
I may be mistaken, as English is not my first language, but my meaning was that 5$ is considered a small or insignificant amount of money here.
Amongst other things, and in my experience, ease and speed of development.
Not everywhere: UK is 50/50, same with USA and AU. Globally yes, but On the ground in different markets it’s different. We’re uk based e-com and android devices are a minuscule part of our traffic, so we’re doing iOS first.
> It has enough developer momentum behind it and it’s unlike react native a bolt on solution to somehow make it work.
I see React as a web-first framework, and RN as a fast path for porting to mobile. I've heard that flutter has early stage web support, but that it's all based on canvas, which is enough to dissuade me for using it for a web-first app. I'd be curious to know your perspective on this.
I see React as a web-first framework, and RN as a fast path for porting to mobile. I've heard that flutter has early stage web support, but that it's all based on canvas, which is enough to dissuade me for using it for a web-first app. I'd be curious to know your perspective on this.
Not the OP but React-native support for the web is also very early stage, I don't think I would use either for building a web platform.
This isn’t quite accurate, it’s mature enough for Twitter to use it for their new site for example (and to hire the creator of react-native-web): https://twitter.com/necolas/status/913877194199359488?s=21
I'm quite surprised by that, I've tried myself react-native-web and found it a bit limited. Maybe it has improved since then.
It's not something I've attempted yet, but I'm under the impression that a React -> React Native port is easier than building a Flutter app for Mobile, and then doing something else for web. Might be wrong?
With React Native you would also have to rewrite your components, it's unlikely your average React component would work without web dom & css.
That's stating the obvious. Of course the UI would need re-implementation. Just like in Flutter, you might have a different UI for Cupertino and Android flavours, except with React, you'd have generic UI for mobile in RN (for better or worse), and your dom/css for React. You would be able to re-use much of the javascript logic and have .tsx as the consistent language throughout the code base. Ideally...
React Native is still used widely at Facebook. It's never been abandoned. They abandoned HTML5, which is entirely different.
My personal experience with it was as someone who had never developed for mobile or the web before, and I have to say I really appreciated it.
Dart itself is very simple to pick up basically as you write. It feels like the most generic 'algol family' language imaginable, in a good way.
The widgets itself that the framework provides are very complete and make inuitive sense. This was a big differentiator for me compared to my modest experiences with react a while ago.
As someone who doesn't live in the world of UI and end-user software at all react was not easy for me because I had to learn javascript and css and html and so on. When the last thing you've built UI wise is Java desktop apps ten years ago that's not easy. Flutter felt much more like a traditional desktop framework in how high-level and complete it is.
Dart itself is very simple to pick up basically as you write. It feels like the most generic 'algol family' language imaginable, in a good way.
The widgets itself that the framework provides are very complete and make inuitive sense. This was a big differentiator for me compared to my modest experiences with react a while ago.
As someone who doesn't live in the world of UI and end-user software at all react was not easy for me because I had to learn javascript and css and html and so on. When the last thing you've built UI wise is Java desktop apps ten years ago that's not easy. Flutter felt much more like a traditional desktop framework in how high-level and complete it is.
I've worked on Dart and Flutter last year on a startupish project. I can say flutter is amazing. It got good ideas from react architecture (eg: managing state and declarative UI) and add many good things like very rich and well designed API. writing UI in language and without other markup language like XML is amazing. You also save a lot of cost to developing in parallel for multiple platform's.
Dart is also a pleasant language, here are some pros and cons about language.
pros:
1- Everything is object. (no more inconsistencies like Java primitives, null and generics)
2- It has very well designed generics and you can access generic type in run time.
3- Good Type inference.
4- Has powerful facilities for asynchronous programming.(eg: async await, coroutines ,...)
5- Not overall bad or complex type system. Compare to Golang or java dart's type system is vastly superior.
some cons:
1- Everything can be null (null is also object).
2- Lack of Union and algebraic data types.
3- Lack of python's like tuple.(eg: (1,'string'))
4- I personally dislike C-style type definition and mandatory semicolon (eg: int foo=23; rather than foo : int=23 )
pros:
1- Everything is object. (no more inconsistencies like Java primitives, null and generics)
2- It has very well designed generics and you can access generic type in run time.
3- Good Type inference.
4- Has powerful facilities for asynchronous programming.(eg: async await, coroutines ,...)
5- Not overall bad or complex type system. Compare to Golang or java dart's type system is vastly superior.
some cons:
1- Everything can be null (null is also object).
2- Lack of Union and algebraic data types.
3- Lack of python's like tuple.(eg: (1,'string'))
4- I personally dislike C-style type definition and mandatory semicolon (eg: int foo=23; rather than foo : int=23 )
As for nulls, non-nullability is currently in the works: https://github.com/dart-lang/language/blob/master/accepted/f...
serious question: how effectively can things like non-nullability be bolted onto a language after it and a large part of its ecosystem has been created?
I see the plan to allow libraries to opt-in and migrate that way.. but I wonder how long that migration will take and if it will ever actually be completed?
I see the plan to allow libraries to opt-in and migrate that way.. but I wonder how long that migration will take and if it will ever actually be completed?
Isn't a tuple just a const List? Also there is a set union function: https://api.flutter.dev/flutter/dart-core/Set/union.html
A tuple usually has different properties compared to a Tuple.
For example, you can have a List of type List<string>, which would be a list of any length containing any string.
On the other hand, a good tuple implementation (especially a typed one) could allow tuples like (string, integer, boolean), i.e. only arrays of length 3, where the first positions holds a string, the second position holds an integer and the third position holds a boolean. So yes, usually they are represented as arrays, but on a higher level, they are fundamentally different.
As for unions, the parent comment is not referring to the Set operation, he's referring to Union Types.
With this concept, a variable can be one of many types. For example: var input: string | number And at Runtime you would have to find out whether it is a string or a number, to be able to use it.
(Not here arguing whether Dart does or does not have these language features, just trying to clarify this misunderstanding)
For example, you can have a List of type List<string>, which would be a list of any length containing any string.
On the other hand, a good tuple implementation (especially a typed one) could allow tuples like (string, integer, boolean), i.e. only arrays of length 3, where the first positions holds a string, the second position holds an integer and the third position holds a boolean. So yes, usually they are represented as arrays, but on a higher level, they are fundamentally different.
As for unions, the parent comment is not referring to the Set operation, he's referring to Union Types.
With this concept, a variable can be one of many types. For example: var input: string | number And at Runtime you would have to find out whether it is a string or a number, to be able to use it.
(Not here arguing whether Dart does or does not have these language features, just trying to clarify this misunderstanding)
Small correction. For union types you cover all cases at compile (build) time, not at runtime. This is pretty valuable in catching bugs.
Yes, that is basically correct, but I think your assertions that "you cover all the cases" and "valuable in catching bugs" are not correct.
For example, in C, you can define a Union type that can hold either a string or an integer, declare a variable of that type and initialize it with a string, and then simply assert that it is an integer.
I think that with your assertion of "valuable in catching bugs" you are referring to Sum Types (often called tagged unions). For Sum Types, if a language supports this concept, it usually also forces you to cover all cases at compile time, whereas with plain unions, you can shoot yourself in the foot, if you're willing to do so.
For example, in C, you can define a Union type that can hold either a string or an integer, declare a variable of that type and initialize it with a string, and then simply assert that it is an integer.
I think that with your assertion of "valuable in catching bugs" you are referring to Sum Types (often called tagged unions). For Sum Types, if a language supports this concept, it usually also forces you to cover all cases at compile time, whereas with plain unions, you can shoot yourself in the foot, if you're willing to do so.
Yes I'm referring specifically to tagged unions in a typed (type safe) language. That's what I thought you we're referencing when you said "var input: string | number". Excuse my pedantry if I misunderstood.
Ah, thanks for explaining that
> Secondly (and this can be seen as both a flaw and an advantage), both Flutter and Dart come from Google. The good part of it is that Google is a tech giant, and if they want to maintain something, they have the resources and manpower to do it. The bad part is that while Google is known to introduce useful tech and services, it’s also known to kill off or retire them when they’re deemed obsolete.
I think over time the crippling of Google’s developer initiatives because of this perception will cost a lot more than all the money saved from all the retired services.
I think over time the crippling of Google’s developer initiatives because of this perception will cost a lot more than all the money saved from all the retired services.
I don't think so (and I'm the type of person to never miss a good Google bashing). And here's the hot take i'll make for it: Google is not solely responsible for the bad PR they get for prematurely retiring popular services.
Often this is a conundrum of naive technologists clamoring to shove untested tools into production for... reasons? Excitement? Risk-taking adrenaline? I'm not quite sure.
Yes Google's marketing oversells (or even lies a la Google Stadia), but at the end of the day I think Google SREs/devs/evangelists expect (wrongly) some measure of common sense and restraint from users and that is just not there. For example, if you ever watched some of Kelsey Hightower's earlier kubernetes talks he practically begs users to deeply consider their use case and whether or not they should actually be using kubernetes.
Google also expects their users to SRE/devops/refactor/upgrade constantly like they're able to. Which is also insanely unrealistic.
Ultimately, while some cases are Google's fault, often the blame is shared - most of the time. The market realizes this and thus the opportunity cost is already priced in somehow.
Often this is a conundrum of naive technologists clamoring to shove untested tools into production for... reasons? Excitement? Risk-taking adrenaline? I'm not quite sure.
Yes Google's marketing oversells (or even lies a la Google Stadia), but at the end of the day I think Google SREs/devs/evangelists expect (wrongly) some measure of common sense and restraint from users and that is just not there. For example, if you ever watched some of Kelsey Hightower's earlier kubernetes talks he practically begs users to deeply consider their use case and whether or not they should actually be using kubernetes.
Google also expects their users to SRE/devops/refactor/upgrade constantly like they're able to. Which is also insanely unrealistic.
Ultimately, while some cases are Google's fault, often the blame is shared - most of the time. The market realizes this and thus the opportunity cost is already priced in somehow.
>Often this is a conundrum of naive technologists clamoring to shove untested tools into production for... reasons? Excitement? Risk-taking adrenaline? I'm not quite sure.
My understanding is that you get promoted at Google for launching new things, not for maintaining them, so there's a perverse incentive to launch projects that become orphans almost immediately. So much so that I wouldn't even say that they retire popular services prematurely, but that because there is no institutional will nor support for these projects to survive into the future, they are simply de-launching proofs of concepts. Translation: nothing is intended to survive at Google besides search and AdWords, and everything else is subject to cancellation at any moment without warning.
I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
My understanding is that you get promoted at Google for launching new things, not for maintaining them, so there's a perverse incentive to launch projects that become orphans almost immediately. So much so that I wouldn't even say that they retire popular services prematurely, but that because there is no institutional will nor support for these projects to survive into the future, they are simply de-launching proofs of concepts. Translation: nothing is intended to survive at Google besides search and AdWords, and everything else is subject to cancellation at any moment without warning.
I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
I think it's a dichotomy where half of the thinking is bonus-oriented as you describe, and the other half is them wrongly assuming all users think/work as they do and will thoroughly evaluate before making a meaningful decision to purchase or put into production (because surely everyone has massive SRE/QA budgets and only does 10 hours of relevant work a week and the rest is for deep optimization). Thus you get the outcome of releasing beta products and then be surprised when either the product is a disappointment, or it gets yanked later due to poor/unideal adoption.
> I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
I'm not sure if it's sufficient cause either, I just try to peel back the onion to understand more then just "those people are dumb profiteers with simple minds making simple mistakes". Also I think it yields some unique insight into my own work/coding/life when I identify the deeper subconscious flaws in product development.
> I'm not sure what you're saying about sharing blame, that these products are too popular? I'm not sure that's a sufficient reason, but it would certainly explain Google's overarching product strategy through the decades.
I'm not sure if it's sufficient cause either, I just try to peel back the onion to understand more then just "those people are dumb profiteers with simple minds making simple mistakes". Also I think it yields some unique insight into my own work/coding/life when I identify the deeper subconscious flaws in product development.
In addition to what you said, I feel that may be Google's view of a viable project (business-wise) is different from many others, hence any real drive to continue these POCs long term.
If we look at main projects/products at Google like Chrome, Search, Gmail, Android, YouTube, Maps, Kuberenetes none of them has any serious competitors out there (except for Android perhaps). I mean, sure we technologists are more aware of alternatives and open to try new things but almost every average user I know is utterly uninterested in an alternative. There's a perception of Google as simply being the most technologically capable company on the planet for average users and that any alternative simply can't match, let alone surpass, Google's offering. Sometimes, when I think about, there's some truth to the latter part of that sentiment. Google does a good job with the projects that actually last.
So, perhaps any project that can't have a similar traction in the market probably doesn't get a whole lot of attention on a collective level.
If we look at main projects/products at Google like Chrome, Search, Gmail, Android, YouTube, Maps, Kuberenetes none of them has any serious competitors out there (except for Android perhaps). I mean, sure we technologists are more aware of alternatives and open to try new things but almost every average user I know is utterly uninterested in an alternative. There's a perception of Google as simply being the most technologically capable company on the planet for average users and that any alternative simply can't match, let alone surpass, Google's offering. Sometimes, when I think about, there's some truth to the latter part of that sentiment. Google does a good job with the projects that actually last.
So, perhaps any project that can't have a similar traction in the market probably doesn't get a whole lot of attention on a collective level.
Chrome has competitors! It has majority market share, but other browsers get usage too.
I think the risk of Flutter getting cancelled is very remote. Google knows they have a winner on their hands.
Flutter is the UI framework for Fuschia. It is picking up huge momentum [1]. The support for native apps and web[2] is still immature, but promising.
Flutter brings the joy back into UI development. No messing with CSS, tables, etc. - "everything is a widget" makes for a very composable framework that is super fun to use.
[1] https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2... [2] https://flutter.dev/web
Flutter is the UI framework for Fuschia. It is picking up huge momentum [1]. The support for native apps and web[2] is still immature, but promising.
Flutter brings the joy back into UI development. No messing with CSS, tables, etc. - "everything is a widget" makes for a very composable framework that is super fun to use.
[1] https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2... [2] https://flutter.dev/web
I don't see any reason Google wouldn't cancel Fuchsia at a moment's notice. It's been consuming their resources for years and is far from launching in a product, and Google happily cancels even established well-used products.
I don’t know why people tried to hide your post. Yes, it’s entirely plausible that Fuchsia is killed in favor of Android evolution not revolution.
Plausible, but i wouldn’t put odds on anything.
LUCKILY, for me because i really like Flutter, I think it hits critical mass soon and wouldn’t matter if Google killed Fuchsia.
Plausible, but i wouldn’t put odds on anything.
LUCKILY, for me because i really like Flutter, I think it hits critical mass soon and wouldn’t matter if Google killed Fuchsia.
You both say this but the interesting thing is that Fuchsia support is creeping up in more essential low level software like LLVM, Rust, WebKit and the devs actually have Chrome already running on the platform for years. Dart/Flutter is used throughout the OS and used in many apps today.
From day 0 on launch, you can expect Fuchsia to run your Dart apps and to run existing Android apps via a tool called Machina (Zircon hypervisor running Linux kernel). If Fuchsia benefits from the Flutter apps being made and gives Google more complete control over the OS unlike Android, then it looks highly unlikely that it will be killed.
In reality as Fuchsia is being ’dog-fooded’ on Google devices it is increasingly likely that Android will be killed.
From day 0 on launch, you can expect Fuchsia to run your Dart apps and to run existing Android apps via a tool called Machina (Zircon hypervisor running Linux kernel). If Fuchsia benefits from the Flutter apps being made and gives Google more complete control over the OS unlike Android, then it looks highly unlikely that it will be killed.
In reality as Fuchsia is being ’dog-fooded’ on Google devices it is increasingly likely that Android will be killed.
The fact that ChromeOS had to gain Android support speaks loudly about what might win in the end.
If Fuchsia ever gets released, I bet ART will replace Flutter.
It is already being ported to run on Fuchsia anyway.
If Fuchsia ever gets released, I bet ART will replace Flutter.
It is already being ported to run on Fuchsia anyway.
ART isn't a UI framework, it can't "replace" Flutter. You can run Flutter apps in ART, the article even talks about doing so.
Indeed it the basis of the Android stack, so it plugs naturally with everything written in Java and Kotlin for Android.
Flutter has zero relationship with ART, it just plugs into Android via the NDK, like anyone else using C++ code.
Flutter has zero relationship with ART, it just plugs into Android via the NDK, like anyone else using C++ code.
I'm pretty sure they either use it on the Nest Hub or are close to it.
One more thing: the entire Google Ads Frontend has been re-written in Dart. This was a very significant, multi-year investment which usually happens at most once in a decade. And... this particular product gives paychecks to everyone else, of course including the Dart team (and core infra team as well).
Dart is picking "huge momentum" and to prove that claim, you link a graph that shows it at rank... I don't know, about 30 or so, which probably amounts to 0.01% mind share.
Where's that "huge" momentum?
Where's that "huge" momentum?
This is the opposite of huge momentum.
I tried out flutter in the past few weeks and it seems really great, especially compared to the android framework. Dart also seems to fit in really well.
But I do have some criticism for dart. While it's nice that they moved to a static types, they still made every single type nullable. So e.g. if you get a boolean in your function, be aware that it can be true, false and also null. I have my problems with java having nullable objects, but having the primitives also be nullable?
Well, I'm pretty much a beginner, so maybe there are better ways and I still don't know them. But afaik, they weren't mentioned in the brief Dart intro on the flutter page.
Dart does also have some cool things, though: Extensions (for adding interfaces to existing types), explicit getters, async/await and lots of syntactic sugar. Building your widget-tree in dart sometimes looks like a declarative style similar to xml, but far more concise, except that it's really imperative, which is really cool. No long
Component a = new Component();
a.setOnClickHandler(xyz);
a.setColor("green");
b.add(a);
chains anymore!
But I do have some criticism for dart. While it's nice that they moved to a static types, they still made every single type nullable. So e.g. if you get a boolean in your function, be aware that it can be true, false and also null. I have my problems with java having nullable objects, but having the primitives also be nullable?
Well, I'm pretty much a beginner, so maybe there are better ways and I still don't know them. But afaik, they weren't mentioned in the brief Dart intro on the flutter page.
Dart does also have some cool things, though: Extensions (for adding interfaces to existing types), explicit getters, async/await and lots of syntactic sugar. Building your widget-tree in dart sometimes looks like a declarative style similar to xml, but far more concise, except that it's really imperative, which is really cool. No long
Component a = new Component();
a.setOnClickHandler(xyz);
a.setColor("green");
b.add(a);
chains anymore!
> they still made every single type nullable
NNBD is almost here: https://github.com/dart-lang/language/blob/master/accepted/f...
NNBD is almost here: https://github.com/dart-lang/language/blob/master/accepted/f...
I tried Flutter a year or two ago after coding Android and iOS apps (to a lesser extent) for years and years.
The dev experience was lightyears ahead of Android. Dart was nice fit. I came upon some edge-cases where Flutter's API seemed immature. But as far as quickly getting apps/prototypes out there, there was no competition.
My main roadblock: the UI was centered around Material design. To use the iOS widgets, which looked good, it seemed you need to put a load of if statements to use the iOS widgets instead - and this felt hugely cludgey.
I'll reiterate what another poster said: if your business depends on apps, go native. Flutter will get you to 90 or 95% really quickly but it's probably that 5% that gives you an edge.
I'd use Flutter when apps are of secondary importance to the business, and when we need an iOS and Android app, and I want it done without spending huge amounts of effort.
The dev experience was lightyears ahead of Android. Dart was nice fit. I came upon some edge-cases where Flutter's API seemed immature. But as far as quickly getting apps/prototypes out there, there was no competition.
My main roadblock: the UI was centered around Material design. To use the iOS widgets, which looked good, it seemed you need to put a load of if statements to use the iOS widgets instead - and this felt hugely cludgey.
I'll reiterate what another poster said: if your business depends on apps, go native. Flutter will get you to 90 or 95% really quickly but it's probably that 5% that gives you an edge.
I'd use Flutter when apps are of secondary importance to the business, and when we need an iOS and Android app, and I want it done without spending huge amounts of effort.
So this article [1] matches my own recollection. Like many projects that originate from Google, it always struck me as a solution looking for a problem.
The first "problem" was Javscript.
At one presentation about this I recall that Lars Bak (IIRC) took quite a beating about DArt, just in terms of the questions asked, to the point that someone had to point out just how much he'd accomplished (ie V8). This was, in essence, an appeal to authority.
I recall the Ads PA basically stepping in to save the project. I can only speculate why but my best guess is the AdWords TL woke up one day and decided to rewrite AdWords in Dart (as he allegedly had with GWT some years before). But all that's pure speculation.
The second "problem" that Dart solved was using the same code on client and server, something Google is inexplicably obsessed with (eg GWT). I don't know what caveats came with Dart but GWT had plenty (eg for many years it wasn't possible to use the same protobuf classes on client and server).
I believe the intent with Dart was, at one point, to run natively within Chrome (the article mentions Dartium). This worked out really well for vbscript. No one wants to write different languages for different browsers. Again, I speculate here, but my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome and that was the end of that.
Maybe it's just me but TypeScript just seemed far more sane.
So... Flutter. I don't know why a UI library needs to be language-specific but it strikes me as a bad idea. Now, the counterpoint is that Flutter is an SDK And more akin to, say, React Native (albeit with significant architectural differences) but I don't think it started that way.
:UI frameworks, libraries and SDKs just don't seem to be in Google's wheelhouse (as opposed to, say, infra, which very much does). I can only speculate as to why but my best guess is Google engineers (disclaimer: Xoogler) can't see passed something as an engineering problem, so much so that they take on philosophies no one asked for or needed (eg same code on client and server), which come with a huge cost and no tangible benefits.
[1]: https://insights.dice.com/2019/03/27/fall-rise-dart-google-j...
The first "problem" was Javscript.
At one presentation about this I recall that Lars Bak (IIRC) took quite a beating about DArt, just in terms of the questions asked, to the point that someone had to point out just how much he'd accomplished (ie V8). This was, in essence, an appeal to authority.
I recall the Ads PA basically stepping in to save the project. I can only speculate why but my best guess is the AdWords TL woke up one day and decided to rewrite AdWords in Dart (as he allegedly had with GWT some years before). But all that's pure speculation.
The second "problem" that Dart solved was using the same code on client and server, something Google is inexplicably obsessed with (eg GWT). I don't know what caveats came with Dart but GWT had plenty (eg for many years it wasn't possible to use the same protobuf classes on client and server).
I believe the intent with Dart was, at one point, to run natively within Chrome (the article mentions Dartium). This worked out really well for vbscript. No one wants to write different languages for different browsers. Again, I speculate here, but my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome and that was the end of that.
Maybe it's just me but TypeScript just seemed far more sane.
So... Flutter. I don't know why a UI library needs to be language-specific but it strikes me as a bad idea. Now, the counterpoint is that Flutter is an SDK And more akin to, say, React Native (albeit with significant architectural differences) but I don't think it started that way.
:UI frameworks, libraries and SDKs just don't seem to be in Google's wheelhouse (as opposed to, say, infra, which very much does). I can only speculate as to why but my best guess is Google engineers (disclaimer: Xoogler) can't see passed something as an engineering problem, so much so that they take on philosophies no one asked for or needed (eg same code on client and server), which come with a huge cost and no tangible benefits.
[1]: https://insights.dice.com/2019/03/27/fall-rise-dart-google-j...
Can't similar things be said for node.js and other tech? Electron apps perhaps? What problems did these technologies solve?
Mostly I agree with you, but coming from desktop development, I also sometimes feel like javascript and the web in general is a mess, and prefer things in a familiar format. As so I don't find things like "DArt" or "Flutter" as surprising...
Mostly I agree with you, but coming from desktop development, I also sometimes feel like javascript and the web in general is a mess, and prefer things in a familiar format. As so I don't find things like "DArt" or "Flutter" as surprising...
> node.js
I don't have a strong opinion on Node.
> Electron apps perhaps?
Hate them with a passion.
> What problems did these technologies solve?
Node.js to is primarily a platform for high-concurrency event-driven request handling where each request itself is a single thread. In my day job I primarily write Hack (PHP) nowadays. PHP embraced this model years ago and I, personally, think it's pretty much ideal for something most often used to service HTTP requests. You almost never want to be in the business of starting and coordinating threads. It gains you a lot of complexity and a lot more failure modes for very little benefit over the single thread per request model (combined with async/await programming, in particular).
Electron is, in my opinion, trash. It's a cheap and crappy way for people to create desktop apps that have a much larger attack surface than any native desktop app (being the entire Chrome runtime) and a huge memory footprint all for the privilege of being able to use HTML/CSS to layout your app.
> and prefer things in a familiar format
So this explains a lot of the things you see from Google. Google engineers, in general, look down on Javascript. There's actually a hierarchy. The C++ engineers look down on anything that isn't C++. Java engineers look down on anything that isn't C++/Java (and sometimes even C++ is looked down on) and so on.
A lot of Google JS is written for the Closure compiler. This was an early effort to add type hints to JS code. If you look at the code you can tell it's written by Java engineers. I like to quip that "Closure puts the Java into Javascript". The JsDoc comment format is basically Javadoc. The type system is familiar to those coming from Java.
So you have GWT, which seemed to appeal to people who though tit would allow them to not need to know anything about JS [insert standard reference to the Joel Spolsky's "leaky abstraction" essay].
Closure tries to remake JS into Java.
What these things tell you is the people coming up with these ideas don't really understand Javascript and more to the point, they don't think they have to nor do they want to.
> I also sometimes feel like javascript and the web in general is a mess
Everything is a mess if you look closely enough.
I don't have a strong opinion on Node.
> Electron apps perhaps?
Hate them with a passion.
> What problems did these technologies solve?
Node.js to is primarily a platform for high-concurrency event-driven request handling where each request itself is a single thread. In my day job I primarily write Hack (PHP) nowadays. PHP embraced this model years ago and I, personally, think it's pretty much ideal for something most often used to service HTTP requests. You almost never want to be in the business of starting and coordinating threads. It gains you a lot of complexity and a lot more failure modes for very little benefit over the single thread per request model (combined with async/await programming, in particular).
Electron is, in my opinion, trash. It's a cheap and crappy way for people to create desktop apps that have a much larger attack surface than any native desktop app (being the entire Chrome runtime) and a huge memory footprint all for the privilege of being able to use HTML/CSS to layout your app.
> and prefer things in a familiar format
So this explains a lot of the things you see from Google. Google engineers, in general, look down on Javascript. There's actually a hierarchy. The C++ engineers look down on anything that isn't C++. Java engineers look down on anything that isn't C++/Java (and sometimes even C++ is looked down on) and so on.
A lot of Google JS is written for the Closure compiler. This was an early effort to add type hints to JS code. If you look at the code you can tell it's written by Java engineers. I like to quip that "Closure puts the Java into Javascript". The JsDoc comment format is basically Javadoc. The type system is familiar to those coming from Java.
So you have GWT, which seemed to appeal to people who though tit would allow them to not need to know anything about JS [insert standard reference to the Joel Spolsky's "leaky abstraction" essay].
Closure tries to remake JS into Java.
What these things tell you is the people coming up with these ideas don't really understand Javascript and more to the point, they don't think they have to nor do they want to.
> I also sometimes feel like javascript and the web in general is a mess
Everything is a mess if you look closely enough.
Does Hack somehow add async to php (like swoole?). It seems to me that PHP and Node are pretty different. PHP is thread per connection and no async, node is just one single thread and you write as much async as you can. Pretty different modes of thinking apply.
I don’t understand the electron hate. VSCode is an electron app and is amazing. It continues to get developer mindshare like wildfire.
Electron promises same code works on web, Mac, Windows, Linux. I don’t see anything come close to it’s offering.
Surely I’d love electron to share the memory footprint with installed chrome. The execution could be improved (I imagine someone at MS is working on it, now that Edge is also Chromium powered).
Electron promises same code works on web, Mac, Windows, Linux. I don’t see anything come close to it’s offering.
Surely I’d love electron to share the memory footprint with installed chrome. The execution could be improved (I imagine someone at MS is working on it, now that Edge is also Chromium powered).
> my strong suspicion is the Chrome team killed the idea of shipping a Dart VM in Chrome
Yeah in a video last year, Lars said "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://www.youtube.com/watch?v=mPna6D21Eqg&feature=youtu.be...
Yeah in a video last year, Lars said "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://www.youtube.com/watch?v=mPna6D21Eqg&feature=youtu.be...
Shipping a new language in your browser is no trivial task.
Using Dart in flutter feels like Google was trying to avoid tossing away a bunch of pre-existing work by finding a purpose for it somewhere. It's Lars' sorta Java, sorta Javascript personal project and it just doesn't have any sort of design to it. Dart's failure in the web space showed that there wasn't any real demand for it - it just wasn't better enough.
I realize they can't use Java, but this is a weird horse to tie themselves to.
I realize they can't use Java, but this is a weird horse to tie themselves to.
They certainly did find a new purpose for Dart outside of it being used in parts of their Ads platform, but
Flutter, when is was the chrome experiment called sky, first started out using Javascript.
The chrome guys decided to move on and look at several language before going with Dart, Swift may have been an option, if it was opensource at the time.
Seems a reason for Dart's failure in the web space was mobile.
Lar gave a talk last year about his and Kasper iot startup https://www.toitware.com/ he mentions why dart didn't make it into chrome, saying "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://youtu.be/mPna6D21Eqg
The chrome guys decided to move on and look at several language before going with Dart, Swift may have been an option, if it was opensource at the time.
Seems a reason for Dart's failure in the web space was mobile.
Lar gave a talk last year about his and Kasper iot startup https://www.toitware.com/ he mentions why dart didn't make it into chrome, saying "then the whole mobile shift happen and there was no room for extra stuff in chrome" https://youtu.be/mPna6D21Eqg
[deleted]
Going with a less-popular language without a killer app yet has its advantages. When you're making a new UI platform it's helpful if you can ask the language team to make changes to the language for you.
Once a language is in use in many places, you can't do that anymore.
Apple did this too when they wanted a language that was compatible with Objective C.
And this is how JavaScript got started, after all.
Once a language is in use in many places, you can't do that anymore.
Apple did this too when they wanted a language that was compatible with Objective C.
And this is how JavaScript got started, after all.
Its a really, really good language - there's links in another post to programming usage ranking blogs, Dart has spiked over the last year, and they note "for languages, frameworks lead adoption"
HN: I won't use anything Google makes, they always shut stuff down.
Also HN: I'm all in on Go.
HN: Learn a new language every year, it's easy and worth it even the language isn't useful for anything. Also HN: I won't learn a new language that would allow me to double my mobile dev productivity because someone told me it was bad 8 years ago.
HN: Learn a new language every year, it's easy and worth it even the language isn't useful for anything. Also HN: I won't learn a new language that would allow me to double my mobile dev productivity because someone told me it was bad 8 years ago.
It's almost as if HN is a community made of different people with different opinions and not a singular entity.
This isn't about who likes what, it's about inconsistent reasoning.
If Google creating a language is reason to believe it will die, why does that apply to Dart and not Go?
This assumes you've observed the much higher popularity for Go and lack of it for Dart here on HN (and most elsewhere).
If Google creating a language is reason to believe it will die, why does that apply to Dart and not Go?
This assumes you've observed the much higher popularity for Go and lack of it for Dart here on HN (and most elsewhere).
Go is used at a bunch of major companies outside Google. Dart is only used in Flutter (and apparently Fuchsia).
Dart overlaps in goals almost completely with Typescript which is heavily used multiple teams within Google.
Switching Flutter to Typescript is something I could easily see happening if Google wanted Flutter to be truly popular.
Dart overlaps in goals almost completely with Typescript which is heavily used multiple teams within Google.
Switching Flutter to Typescript is something I could easily see happening if Google wanted Flutter to be truly popular.
> Dart overlaps in goals almost completely with Typescript
As I see it, that's not all that true.
Now, it's true, that it's non-native use competes with TypeScript in domain and shares some implementation method details in that domain (e.g., both are languages that rely on compilation to JS in the web domain), but the goals clearly aren't the same. TypeScript's goals are basically limited to static typing and source compatibility with modern JavaScript (that is, it is an goal to be a typed superset of JS.)
Dart has a wide array of different goals, including being a typed replacement for JS that is not limited in its other goals by being source-compatible with JS.
As I see it, that's not all that true.
Now, it's true, that it's non-native use competes with TypeScript in domain and shares some implementation method details in that domain (e.g., both are languages that rely on compilation to JS in the web domain), but the goals clearly aren't the same. TypeScript's goals are basically limited to static typing and source compatibility with modern JavaScript (that is, it is an goal to be a typed superset of JS.)
Dart has a wide array of different goals, including being a typed replacement for JS that is not limited in its other goals by being source-compatible with JS.
> HN: I won't use anything Google makes, they always shut stuff down.
You are talking about an extremely vocal minority, who inevitably ends up creating echo chambers.
Like everything on earth there are both good and bad vocal minorities. I follow this heuristic about vocal minorities: ignore them when it comes to trivial issues. Online vocal minorities like fanboys who harass directors, writer, or actors are good example of this group. Same goes for the people who constantly complain about Google shutting down some free products. OTOH, I keep close eyes on activists, who are vocal minorities and are fighting for important issues. Activists might not be on the right side of history on every issue, but these are the people who fought for civil rights, LGBTQ rights etc., often at their own personal expense.
You are talking about an extremely vocal minority, who inevitably ends up creating echo chambers.
Like everything on earth there are both good and bad vocal minorities. I follow this heuristic about vocal minorities: ignore them when it comes to trivial issues. Online vocal minorities like fanboys who harass directors, writer, or actors are good example of this group. Same goes for the people who constantly complain about Google shutting down some free products. OTOH, I keep close eyes on activists, who are vocal minorities and are fighting for important issues. Activists might not be on the right side of history on every issue, but these are the people who fought for civil rights, LGBTQ rights etc., often at their own personal expense.
Is there a good example of a great, native feeling Flutter UI? I just downloaded a couple of random “Flutter gallery” type Apps from the iOS App Store and both of them have animations and text rendering that feel “wrong” (and somewhat janky in the case of the animations).
This may reflect more on the development of those particular apps than the framework though, hence my asking - in my experience, React Native does a pretty good job of feeling “native” by default in most cases.
Not saying users would necessarily care so much, but I’m interested regardless - I wonder if there have been any studies/anecdotes into how sensitive users are to “details” like animation etc. in terms of engagement.
This may reflect more on the development of those particular apps than the framework though, hence my asking - in my experience, React Native does a pretty good job of feeling “native” by default in most cases.
Not saying users would necessarily care so much, but I’m interested regardless - I wonder if there have been any studies/anecdotes into how sensitive users are to “details” like animation etc. in terms of engagement.
> in my experience, React Native does a pretty good job of feeling “native” by default in most cases.
As it should. React Native wraps around the native controls of the platform as much as possible. Flutter just renders it's own controls in OpenGL.
As it should. React Native wraps around the native controls of the platform as much as possible. Flutter just renders it's own controls in OpenGL.
Exactly why I'm interested to see good examples of Flutter which don't feel "off".
It's a situation just like electron. Flutter will always feel "off" no matter what is done.
Yeah I guess so. To be fair I don’t mind using some Electron applications, so I guess it shows that if you do it well, it’s maybe not too much of a problem
Native feel? Nope. User don't seem to care though, there are many flutter apps with decent ratings:
https://flutter.dev/showcase
https://flutter.dev/showcase
that's the question i keep asking everytime there's a thread about flutter being great, and so far i haven't received any answer.
my intuition is that flutter is used mostly for business apps made of forms and lists, where expectation in terms of graphical performances are very low.
my intuition is that flutter is used mostly for business apps made of forms and lists, where expectation in terms of graphical performances are very low.
I'd agree with that assessment.
I'm also open to being pointed toward a productionized Flutter app that feels native in the same way as some other x-platform solutions manage to exhibit. It's difficult to sift through the existing live examples.
I'm also open to being pointed toward a productionized Flutter app that feels native in the same way as some other x-platform solutions manage to exhibit. It's difficult to sift through the existing live examples.
I don't think so. I believe Flutter is the new Flash.
They are clearly trying to attract the "brand first" marketing crowd by stressing fast graphics rendering, animations, full customization, etc.
I bet we're going to see a flood of Flutter based retail, fashion, food, sports, motor and lifestyle apps very soon.
They are clearly trying to attract the "brand first" marketing crowd by stressing fast graphics rendering, animations, full customization, etc.
I bet we're going to see a flood of Flutter based retail, fashion, food, sports, motor and lifestyle apps very soon.
Flutter is the best thing that happened to the UI development in the last decade or even two.
Before Flutter, if I needed to build a simple app (couple of screens and network requests), there were no real option except of outsource it to the mobile app development studio. After discovering Flutter I've built and published my first app in 3 days while watching initial Flutter tutorials.
Since then, making mobile apps for my projects has become such a pleasant experience, that I'm now trying Flutter Web as a substitute to the madness of JS/HTML/CSS ecosystem, and I'm quite impressed with a result. It's still in Beta, but the development experience is so much smoother.
At the same time, a lot people still don't know what Flutter even is, so having it in your arsenal is a huge competitive advantage at the moment.
Before Flutter, if I needed to build a simple app (couple of screens and network requests), there were no real option except of outsource it to the mobile app development studio. After discovering Flutter I've built and published my first app in 3 days while watching initial Flutter tutorials.
Since then, making mobile apps for my projects has become such a pleasant experience, that I'm now trying Flutter Web as a substitute to the madness of JS/HTML/CSS ecosystem, and I'm quite impressed with a result. It's still in Beta, but the development experience is so much smoother.
At the same time, a lot people still don't know what Flutter even is, so having it in your arsenal is a huge competitive advantage at the moment.
> there were no real option
React Native, Xamarin, Ionic, and a ton more?
React Native, Xamarin, Ionic, and a ton more?
All those solve the "two codebases" problem by piling levels of complexity one on top of another. It's fire-sure way to make developers unhappy and code unmaintainable in the long run.
React Native was the best shot in this market, but adding the worst UI framework in the history of software – typesetting markup language (HTML), set of global classes for styling with magic words like "!important" (CSS) and hackish scripting language designed under pressure from Sun in 2 weeks (Mocha, renamed to Javascript) - on top of the already complicated stacks yielded all sorts of problems: from dependency management hell to unforgivably slow UI. Even AirBnB – the largest React Native shop over there – abandoned it altogether and returned to native iOS/Android development. My own experience working with React Native project for 1.5 years (with ClojureScript added on top for coolness) just reassured me that 5 layers of complexity is worse than 1 layer :)
Flutter design is so sick, that unless I'm writing own native plugins, I don't even touch iOS/Android layers. So it's basically single layer of complexity from the perspective of the developer and it's a game changer in this field.
React Native was the best shot in this market, but adding the worst UI framework in the history of software – typesetting markup language (HTML), set of global classes for styling with magic words like "!important" (CSS) and hackish scripting language designed under pressure from Sun in 2 weeks (Mocha, renamed to Javascript) - on top of the already complicated stacks yielded all sorts of problems: from dependency management hell to unforgivably slow UI. Even AirBnB – the largest React Native shop over there – abandoned it altogether and returned to native iOS/Android development. My own experience working with React Native project for 1.5 years (with ClojureScript added on top for coolness) just reassured me that 5 layers of complexity is worse than 1 layer :)
Flutter design is so sick, that unless I'm writing own native plugins, I don't even touch iOS/Android layers. So it's basically single layer of complexity from the perspective of the developer and it's a game changer in this field.
There is no HTML or CSS in react native. Are you sure you didn’t work with plain React in a webview instead? I can’t even imagine trying to add another compiler (ClojureScript) to its build process.
AirBnB abandoned it for other reasons - mostly difficulty integrating it with existing native codebases and developer pushback, without fully commuting to it. MS Office, Shopify and a host of other products are fully invested now.
Flutter doesn’t have native UI, so I don’t think it compares well (or will catch up for non-gaming/casual apps).
AirBnB abandoned it for other reasons - mostly difficulty integrating it with existing native codebases and developer pushback, without fully commuting to it. MS Office, Shopify and a host of other products are fully invested now.
Flutter doesn’t have native UI, so I don’t think it compares well (or will catch up for non-gaming/casual apps).
The parent commenter doesn't by into the "madness of javascript", maybe also against c#?
Not super related to the article, but I had to get this off my chest. Suppose you use VSCode on Windows to write a Flutter app targeting the Surface Duo. In that case, you would be using a Microsoft editor running a Google SDK on a Microsoft operating system, targeting a Microsoft distribution of a Google operating system. We've not only come full circle, we've gone in loops.
If mobile is at all critical to your business, then you build in native - period.
I think we've all learned at least that much in the past few years.
A lot of businesses either overestimate or underestimate their mobile product needs because they don't understand the market or the platform. Expectations for an interactive consumer mobile app (Ride-sharing, Social media, Photo editing, etc) are extremely high and it would be foolish to under-invest or try to take shortcuts. At the same time there are ton of businesses (Home listings, Saas tools, Informational apps, etc) that would be well served by a simple React Native app. Know which type of business you are.
I think we've all learned at least that much in the past few years.
A lot of businesses either overestimate or underestimate their mobile product needs because they don't understand the market or the platform. Expectations for an interactive consumer mobile app (Ride-sharing, Social media, Photo editing, etc) are extremely high and it would be foolish to under-invest or try to take shortcuts. At the same time there are ton of businesses (Home listings, Saas tools, Informational apps, etc) that would be well served by a simple React Native app. Know which type of business you are.
Performance critical, for sure, but in more areas than you think: My 2012 thinkpad (i5-3320M) maxes out 100% one of it's CPU while I type on facebook messenger.
If you're doing anything super gestural, with lots of complex animations and transitions, you'll inevitably have to drop down into native to get the interactions right. So it's about more than just performance though that is a big part of it too.
The plethora of companies building mission critical apps on platforms like Ionic and React Native would stand to disprove this
There are two new app only banks here in Switzerland and they both use a cross platform framework. One for sure ionic. On Android these apps are absolute garbage. They are slow to start, slow interaction and slow animation. One of these apps has a main.js in it that has over 200k lines of crap with hundreds of lines of if (ios) and if (android). All the iOS styles are packed in the Android apk which is just stupid.
If these banks want to compete with revolut or transferwise they need to provide an app that's isn't garbage.
If these banks want to compete with revolut or transferwise they need to provide an app that's isn't garbage.
My local bank has a native app as far as I can tell and it regularly takes over 10 seconds to get past the login page. My credit card (Discover) app somehow won an award for best UX in the industry and still takes over 5 seconds to log in (both of these are with Face ID by the way).
Contrast this to Robinhood, which jumps from cold boot to main screen in about a second.
The problem is not the frameworks, it is poor development practices. Until the big guys learn that outsourcing critical software is a stupid idea, the next generation cool kid apps will continue to eat at their customer base (until they become relevant enough to be bought out by the big guys, and the cycle repeats).
Contrast this to Robinhood, which jumps from cold boot to main screen in about a second.
The problem is not the frameworks, it is poor development practices. Until the big guys learn that outsourcing critical software is a stupid idea, the next generation cool kid apps will continue to eat at their customer base (until they become relevant enough to be bought out by the big guys, and the cycle repeats).
There is a difference between mission-critical and critical for the business.
For an entity like Snapchat, it is the business. It'd be stupid for them to even think of trying to cut corners to save a few bucks by maybe sharing some code.
For an entity like Snapchat, it is the business. It'd be stupid for them to even think of trying to cut corners to save a few bucks by maybe sharing some code.
Not saying you are wrong at all - building something with highly complex interactions, real time image manipulation etc. such as Snapchat would likely require dropping down to native code for a good part of it - but “maybe sharing some code” isn’t really fair - in my experience, React Native allows you to share the vast majority of code (aside from any native bits, of course).
We’ve built a pretty complex and highly visual music learning app for iOS and Android recently, and thanks to the combination of React Native, Unity and JUCE (C++ audio framework), pretty much all the code is shared. Seeing it run on Android with no big changes needed (aside from audio stuff, which is a challenge on Android in general) for the first time was pretty impressive. Even given unlimited resources, I’m not sure I’d choose to go down the 2 native apps route - automatic feature parity across platforms is a pretty killer feature.
If you were building something like Snapchat where I guess things like app startup time and performance on budget devices are important, I can see why you’d choose to though.
We’ve built a pretty complex and highly visual music learning app for iOS and Android recently, and thanks to the combination of React Native, Unity and JUCE (C++ audio framework), pretty much all the code is shared. Seeing it run on Android with no big changes needed (aside from audio stuff, which is a challenge on Android in general) for the first time was pretty impressive. Even given unlimited resources, I’m not sure I’d choose to go down the 2 native apps route - automatic feature parity across platforms is a pretty killer feature.
If you were building something like Snapchat where I guess things like app startup time and performance on budget devices are important, I can see why you’d choose to though.
Having been there, I hope to never touch Cordova or Ionic ever again.
Most of those apps are perfectly doable as PWAs.
Most of those apps are perfectly doable as PWAs.
That’s too bad, Ionic with Capacitor (and React) is much better and fully supports PWAs.
Over the past two weeks I have seen Shopify, Flipkart, Microsoft Office, Coinbase and others officially throw their weight behind React Native.
I'm also seeing the Expo.io project (ready made starters for React Native) mature to production quality extent.
At this point, I'm seeing a massive production scale behind React Native which doesn't exist in the Flutter world.
Plus the elephant in the room - React. How do you compete against that ? Incidentally, Flutter was inspired by React.
At this point, if I had to take a bet - React Native would win against Flutter definitely. There will still be a massive Java/Kotlin userbase...but I don't see why Flutter will exist in a even-Microsoft-Office-is-using-React-Native world.
I'm also seeing the Expo.io project (ready made starters for React Native) mature to production quality extent.
At this point, I'm seeing a massive production scale behind React Native which doesn't exist in the Flutter world.
Plus the elephant in the room - React. How do you compete against that ? Incidentally, Flutter was inspired by React.
At this point, if I had to take a bet - React Native would win against Flutter definitely. There will still be a massive Java/Kotlin userbase...but I don't see why Flutter will exist in a even-Microsoft-Office-is-using-React-Native world.
Microsoft is not only using React Native, they are the main contributors to React Native on Windows and macOS.
React Native is also one of the reasons why WinUI core components are all going to be C++, instead of a mix of C# and C++.
React Native is also one of the reasons why WinUI core components are all going to be C++, instead of a mix of C# and C++.
“Without losing your hair”
Future common data boilerplate. Qt/gtk-style app init boilerplate. Routing boilerplate. Future builder boilerplate. Homepage title state boilerplate. Setmapsfordicts boilerplate. DTOs. Widget scaffold. Step builder boilerplate. New policy subject(?). Complex handwritten setters and validators.
How on earth is that not losing your hair? Can’t we just drop a list view, few controls on a form, attach field formatters, and then write a simple controller that implements a part of a table view delegate and a save method? What’s wrong with modern ui?
Future common data boilerplate. Qt/gtk-style app init boilerplate. Routing boilerplate. Future builder boilerplate. Homepage title state boilerplate. Setmapsfordicts boilerplate. DTOs. Widget scaffold. Step builder boilerplate. New policy subject(?). Complex handwritten setters and validators.
How on earth is that not losing your hair? Can’t we just drop a list view, few controls on a form, attach field formatters, and then write a simple controller that implements a part of a table view delegate and a save method? What’s wrong with modern ui?
You don't have to do that. you can write everything in one file if you want. But when you introduce some architecture you always have some verbosity
> The bad part is that while Google is known to introduce useful tech and services, it’s also known to kill off or retire them when they’re deemed obsolete.
Do you know any company that doesn't retire a product once it's deemed obsolete?
Do you know any company that doesn't retire a product once it's deemed obsolete?
Most enterprise IT vendor. IBM in particular will support obsolete products for decades (e.g. OS/2). It's part of the reason managers feel comfortable writing them big checks b/c they know that if they make a bet on the technology they will still be able to get support many years later.
Basecamp has a policy against retiring projects with users: https://basecamp.com/about/policies/until-the-end-of-the-int...
> You’ll find the complete app code here [1]
Leads to an empty repository.
[1] https://github.com/asc-lab/personal-insurance-flutter-poc
Leads to an empty repository.
[1] https://github.com/asc-lab/personal-insurance-flutter-poc
Yes, our mistake. Tomorrow we added full code to this repo.
Why Flutter over React Native can anyone answer this question?
It was easy for me.
I know almost no JavaScript. I know C and asm and python. So... looking at the two, guess which one looked better to me?
The code for Dart just makes sense. It’s not beholden to JS or XML or HTML or CSS. It just does it’s own thing.
If you are heavily invested in JS, I bet there are aspects of Flutter that are still appealing, but if your aren’t invested in JS, I see no reason to get in just for React sake.
I know almost no JavaScript. I know C and asm and python. So... looking at the two, guess which one looked better to me?
The code for Dart just makes sense. It’s not beholden to JS or XML or HTML or CSS. It just does it’s own thing.
If you are heavily invested in JS, I bet there are aspects of Flutter that are still appealing, but if your aren’t invested in JS, I see no reason to get in just for React sake.
> I know almost no JavaScript. I know C and asm and python. So... looking at the two, guess which one looked better to me?
I fail to see your point; surely Dart was a new language for you as well?
I fail to see your point; surely Dart was a new language for you as well?
I assume he means that in selecting between two languages, with that given lang background, he made a preference choice of Dart.
As a counterpoint, we have whole swathes of JS engineering teams building new mobile apps and would select react-native / Typescript (and where possible Expo) over Dart.
As a counterpoint, we have whole swathes of JS engineering teams building new mobile apps and would select react-native / Typescript (and where possible Expo) over Dart.
As a JS engineer with experience using react I can say that Flutter/Dart is so much easier from a development perspective then react-native. I've done a little bit of swift development as well and the ease/speed of development is comparable.
Maybe react-native is easier if you don't know react but for me it seems to keep only the worst parts of react and forcing you into using a lot of components for ui that I found to be poorly documented.
Maybe react-native is easier if you don't know react but for me it seems to keep only the worst parts of react and forcing you into using a lot of components for ui that I found to be poorly documented.
If you can manage to remain inside the Expo dev-loop, that personally is my preference for ease and first in class DX.
I’ll definitely continue to observe Flutter/Dart, but the investment/payoff doesn’t appear large enough yet for our use cases.
I’ll definitely continue to observe Flutter/Dart, but the investment/payoff doesn’t appear large enough yet for our use cases.
FWIW, and this is just my personal experience, but I find Dart to be very similar to Typescript, and we have JS engineering teams building out new mobile apps in Dart ;)
Not having to ALSO know JS + XML + HTML + CSS... it looks familiar coming from C.
If Flutter apps are two things, Flutter and Dart. Then React Native apps are six things or so.
If Flutter apps are two things, Flutter and Dart. Then React Native apps are six things or so.
This is a complicated answer that would probably take experience developing real-world applications in both to fully appreciate, but I`ll bite.
A few years ago, I was CTO of a small startup and spent a significant portion of a year building out our mobile app in React Native.
I have experience building cross-platform mobile apps going all the way back from when Ionic was called Apache PhoneGap and was an entirely different product.
In my opinion, React Native is a classic case of follow-the-herd syndrome. This is not to say that React Native is not a viable technology, but simply that it just isn't very good. Let me dive into a few of the things that were really grating when developing on RN:
- The hot-reload times were painstakingly slow. I am talking about 15-20 seconds after save. This really takes a toll on development velocity.
- You have a major decision to make when building an RN app: To use Expo or not. Expo is an SDK which allows you to circumvent needing to drop down into the native build processes for each platform and provides wrapper APIs for accessing native hardware functionality on the phone, with the tradeoff being that a wide number of RN libraries were not compatible since they required being installed as Cocoa Pods or Gradle/Maven packages natively. So you are trading convenience and development speed for flexibility. We chose to go with Expo, and did not regret it.
- Performance is an issue in RN that you need to aggressively optimize against. I remember being aghast that rendering a scrollable list of 300 text items caused so much lag and stuttering it required a full day of manual optimization to calculate viewport area and which cells would be in view to prevent that work from being done by the element on-thread in order to be semi-usable. You have to be really cautious about your render cycles and everything else when building views.
- Doing heavy custom styling requires some hacky workarounds since RN wraps the native UI elements and does not expose all of the style API that they provide.
Later on, at another company, we ended up building an app with NativeScript + Vue which was a much better experience. NativeScript is essentially React Native, but allows you to use any JS/TS framework (or none at all) and has much better APIs for interacting with the device, and allows you to fully style the underlying device-specific UI element if you really need to. And the performance ran circles around RN. The entire experience was overall miles better. Very few people use NativeScript though, just due to the fact you never hear about it.
Ultimately, if I had to give advice, it would be this:
Either write a regular PWA web app, so that you can leverage existing web technologies and all the component libraries, and then add native functionalities and publish to the app store using the Capacitor framework that powers Ionic apps. Or just use Flutter.
Flutter has the only cross-platform mobile experience that does not feel really hacky to me. It does not try to compile to platform-specific view elements, instead compiling to native ARM code, and tries to maintain 120FPS. You can use the same Flutter codebase to generate mobile, web, and desktop apps. And the whole developer experience is really incredible. Instant stateful hot-reloading, screaming performance. Google put a lot of effort and thought into it, and Flutter is not going anywhere given that it powers all of Fuschias UI.
A few years ago, I was CTO of a small startup and spent a significant portion of a year building out our mobile app in React Native.
I have experience building cross-platform mobile apps going all the way back from when Ionic was called Apache PhoneGap and was an entirely different product.
In my opinion, React Native is a classic case of follow-the-herd syndrome. This is not to say that React Native is not a viable technology, but simply that it just isn't very good. Let me dive into a few of the things that were really grating when developing on RN:
- The hot-reload times were painstakingly slow. I am talking about 15-20 seconds after save. This really takes a toll on development velocity.
- You have a major decision to make when building an RN app: To use Expo or not. Expo is an SDK which allows you to circumvent needing to drop down into the native build processes for each platform and provides wrapper APIs for accessing native hardware functionality on the phone, with the tradeoff being that a wide number of RN libraries were not compatible since they required being installed as Cocoa Pods or Gradle/Maven packages natively. So you are trading convenience and development speed for flexibility. We chose to go with Expo, and did not regret it.
- Performance is an issue in RN that you need to aggressively optimize against. I remember being aghast that rendering a scrollable list of 300 text items caused so much lag and stuttering it required a full day of manual optimization to calculate viewport area and which cells would be in view to prevent that work from being done by the element on-thread in order to be semi-usable. You have to be really cautious about your render cycles and everything else when building views.
- Doing heavy custom styling requires some hacky workarounds since RN wraps the native UI elements and does not expose all of the style API that they provide.
Later on, at another company, we ended up building an app with NativeScript + Vue which was a much better experience. NativeScript is essentially React Native, but allows you to use any JS/TS framework (or none at all) and has much better APIs for interacting with the device, and allows you to fully style the underlying device-specific UI element if you really need to. And the performance ran circles around RN. The entire experience was overall miles better. Very few people use NativeScript though, just due to the fact you never hear about it.
Ultimately, if I had to give advice, it would be this:
Either write a regular PWA web app, so that you can leverage existing web technologies and all the component libraries, and then add native functionalities and publish to the app store using the Capacitor framework that powers Ionic apps. Or just use Flutter.
Flutter has the only cross-platform mobile experience that does not feel really hacky to me. It does not try to compile to platform-specific view elements, instead compiling to native ARM code, and tries to maintain 120FPS. You can use the same Flutter codebase to generate mobile, web, and desktop apps. And the whole developer experience is really incredible. Instant stateful hot-reloading, screaming performance. Google put a lot of effort and thought into it, and Flutter is not going anywhere given that it powers all of Fuschias UI.
When React Native started there was Appcelerator Titanium, Xamarin, and others such as Qt and Rubymotion (Ionic was popular too but it’s considered webview).
We may be in Peak React right now as adoption is at an all time high vs Angular and Vue. But tools such as Svelte and Flutter are the next thing that has a chance to be competitive.
Flutter reminds me of Vue, loved by Developers but low adoption (compared to React or Angular). At least Flutter is backed by a giant. Hopefully the adoption rate keeps increasing.
We may be in Peak React right now as adoption is at an all time high vs Angular and Vue. But tools such as Svelte and Flutter are the next thing that has a chance to be competitive.
Flutter reminds me of Vue, loved by Developers but low adoption (compared to React or Angular). At least Flutter is backed by a giant. Hopefully the adoption rate keeps increasing.
> Flutter is not going anywhere given that it powers all of Fuschias UI
That's assuming Fuschia ever becomes a priority. So far, there is no reason to believe it will even launch, let alone be a priority.
That's assuming Fuschia ever becomes a priority. So far, there is no reason to believe it will even launch, let alone be a priority.
Check out “Flutter Versus Other Mobile Development Frameworks: A UI And Performance Experiment”:
https://blog.codemagic.io/flutter-vs-ios-android-reactnative...
https://blog.codemagic.io/flutter-vs-ios-android-reactnative...
I work for a little web-development shop that does the occational app on the side, mostly if an existing customer are interested in having one developed, we don't employ any full time app developers. We have just decided to try out flutter for our next app project. We are close to being done with the actual app development, and it looks like we are going to be done way under budget, so we are very happy with the technology as it currently is.
Before my time, we initially started app development using Cordova. It lined up well with existing expertise in the office as that what we work with most of the time. The apps turned out rather well except for reliability and building. These are by contract applications, so we make them, release them and don't revisit them unless we need to perform support on them. Changes in the web browser, particularity on iOS has broken these apps on several occasions where we have to go back and fix them. Some of these issues have been expected, such as when iPhone X came to market, but sometimes an update has broken something else, seemingly out of the blue.
We decided to try out some new technologies as we we're not too impressed with Cordova and settled on Nativescript + Vue. Again due to expertise with vue as it is one of the technologies we utilize a lot in web projects. Pretty much all of the people who had been involved with the previous apps found it a better experience than Cordova. But in my opinion, it was also quite infuriating to work with. Hot module reloading never truly worked the way it should, we often had to quit and reload the app for changes to be correctly applied. It didn't end up as cross platform as initially thought. We had to make a lot of platform specific components for things we initially didn't think we had to, mostly because the shared options of components in their standard libraries we're not as good as we had hoped. We ended up spending way more time than initially thought wresling components into submission in order to get close to the design we initially envisioned, and we ended up compromising a lot on UI in order to make budget and deadlines. Performance was also something I we had to optimize a lot more for than initially planned. Animations and screen transitions would usually take a performance dive even though our views were very simple and did not really have much data in them at all. We struggled a lot to wrangle UI components into shape, hence why we felt we had to make so many components. And we encountered issues with very simple components such as images in list views not rendering if scrolled out then back in from views.
For this next project I suggested we try flutter before committing more to NativeScript, and we have seen immediate value from this technology over any of the others we have tried.
* We spend way less time on platform specific code, the reusable pieces look more consistent across platforms which means we spend less time tweaking them for either iOS or Android. I think that flutter using its own rendering technique is a serious boon to us who are just making cross platform apps as cheap as possible.
* Any non standard UI component is often way less time consuming to develop in flutter as you don't have to write platform specific version of it. This has also let us cut down on external dependencies which we felt were necessary on Nativescript in order to implement some features in the allotted time available. This is something I think we will appreciate a lot over time, as NativeScript does not have the most active community and the potential work we will have to do to maintain components that may be abandoned by their original developer down the line.
* Tooling works a lot better for flutter. Hot module reloading actually works(most of the time). Statefulness and these reload is not as smooth. Actual breakpoints and debugging is very nice. We could get that with Nativescript too, but only in the javascript code, not for the templates which were written in XML. And if something went wrong on the "native" side, it would be like a black box to us which we could not truly inspect our way into. Flutter allows us to follow the stack deep into any widget.
* When you have to write native code for Flutter, you at least get the help of the tooling built for native platform development, as opposed to NativeScript where you declare that in javascript. It is very seldom needed for the kind of projects we've been doing however so I have no great insights here.
I'm very apathetic towards Dart as a language. It is entirely inoffensive. I felt like I could work in it without even trying to learn it, and I think I have spent at most an hour or two hours to look into and learn the more dart specific language features. I am not that much of a fan of how to deal with JSON data and the dynamic type in there. Dynamic feels a bit accident prone but other than that, Dart as a language gets less on my nerves than some of the more common and frankly way more tedious web related programming languages I have to use daily for work.
As far as the kind of work we're doing, Flutter is great
Before my time, we initially started app development using Cordova. It lined up well with existing expertise in the office as that what we work with most of the time. The apps turned out rather well except for reliability and building. These are by contract applications, so we make them, release them and don't revisit them unless we need to perform support on them. Changes in the web browser, particularity on iOS has broken these apps on several occasions where we have to go back and fix them. Some of these issues have been expected, such as when iPhone X came to market, but sometimes an update has broken something else, seemingly out of the blue.
We decided to try out some new technologies as we we're not too impressed with Cordova and settled on Nativescript + Vue. Again due to expertise with vue as it is one of the technologies we utilize a lot in web projects. Pretty much all of the people who had been involved with the previous apps found it a better experience than Cordova. But in my opinion, it was also quite infuriating to work with. Hot module reloading never truly worked the way it should, we often had to quit and reload the app for changes to be correctly applied. It didn't end up as cross platform as initially thought. We had to make a lot of platform specific components for things we initially didn't think we had to, mostly because the shared options of components in their standard libraries we're not as good as we had hoped. We ended up spending way more time than initially thought wresling components into submission in order to get close to the design we initially envisioned, and we ended up compromising a lot on UI in order to make budget and deadlines. Performance was also something I we had to optimize a lot more for than initially planned. Animations and screen transitions would usually take a performance dive even though our views were very simple and did not really have much data in them at all. We struggled a lot to wrangle UI components into shape, hence why we felt we had to make so many components. And we encountered issues with very simple components such as images in list views not rendering if scrolled out then back in from views.
For this next project I suggested we try flutter before committing more to NativeScript, and we have seen immediate value from this technology over any of the others we have tried.
* We spend way less time on platform specific code, the reusable pieces look more consistent across platforms which means we spend less time tweaking them for either iOS or Android. I think that flutter using its own rendering technique is a serious boon to us who are just making cross platform apps as cheap as possible.
* Any non standard UI component is often way less time consuming to develop in flutter as you don't have to write platform specific version of it. This has also let us cut down on external dependencies which we felt were necessary on Nativescript in order to implement some features in the allotted time available. This is something I think we will appreciate a lot over time, as NativeScript does not have the most active community and the potential work we will have to do to maintain components that may be abandoned by their original developer down the line.
* Tooling works a lot better for flutter. Hot module reloading actually works(most of the time). Statefulness and these reload is not as smooth. Actual breakpoints and debugging is very nice. We could get that with Nativescript too, but only in the javascript code, not for the templates which were written in XML. And if something went wrong on the "native" side, it would be like a black box to us which we could not truly inspect our way into. Flutter allows us to follow the stack deep into any widget.
* When you have to write native code for Flutter, you at least get the help of the tooling built for native platform development, as opposed to NativeScript where you declare that in javascript. It is very seldom needed for the kind of projects we've been doing however so I have no great insights here.
I'm very apathetic towards Dart as a language. It is entirely inoffensive. I felt like I could work in it without even trying to learn it, and I think I have spent at most an hour or two hours to look into and learn the more dart specific language features. I am not that much of a fan of how to deal with JSON data and the dynamic type in there. Dynamic feels a bit accident prone but other than that, Dart as a language gets less on my nerves than some of the more common and frankly way more tedious web related programming languages I have to use daily for work.
As far as the kind of work we're doing, Flutter is great
I wouldn't discount React Native. Microsoft and Shopify are now fully committed to it, and Facebook is committed to fixing the architecture issues that made Airbnb leave it in the first place.
https://www.ideamotive.co/blog/what-to-expect-from-react-nat...
https://reactnative.dev/blog/2019/06/12/react-native-open-so...
https://www.ideamotive.co/blog/what-to-expect-from-react-nat...
https://reactnative.dev/blog/2019/06/12/react-native-open-so...
Do I need to use Dart in order to use Flutter?
Yes, Flutter is Skia + an UI framework written in Dart.
You can also get Skia + whatever you want and get your own "Flutter".
Currently they still have a better experience to sell regarding code reloading, but competing frameworks are upping their game by adding similar capabilities to their developer toolchains.
You can also get Skia + whatever you want and get your own "Flutter".
Currently they still have a better experience to sell regarding code reloading, but competing frameworks are upping their game by adding similar capabilities to their developer toolchains.
Yes. More info about why is here: https://flutter.dev/docs/resources/faq#why-did-flutter-choos...
Yes, the Flutter API is a bunch of libraries written in Dart.
If most of my focus is on Apple platforms (iOS, macOS, tvOS, watchOS, and possibly soon the rumored arOS), I would rather pick SwiftUI over any other framework.
Though at its early stage, as with all new Apple tech, you will still be losing your hair. Hopefully there's only a few months to go until a substantial increase in its stability (and documentation.)
Though at its early stage, as with all new Apple tech, you will still be losing your hair. Hopefully there's only a few months to go until a substantial increase in its stability (and documentation.)
The issue with SwiftUI is that you can't just have "most" of your focus on Apple platforms. You need to have _all_ of the focus on Apple platforms because you can't run it anywhere else.
With Flutter you have all of your focus on most of of the smartphone market practically for free which makes a massive difference in your addressable market.
With Flutter you have all of your focus on most of of the smartphone market practically for free which makes a massive difference in your addressable market.
Yea, if you are Apple only; go for SwiftUI... but who can afford to be Apple only?
I think there are a billion apps that no one cares about because developers have forgot about trying to solve actual problems in favor of “we have an app”.
For us, it was “learn once, write anywhere” for react, or “write once and actually use everywhere” for Flutter. Native wasn’t even a question for the size of the team on this latest project.
We make money by solving problems; not launching some app built with some language
I think there are a billion apps that no one cares about because developers have forgot about trying to solve actual problems in favor of “we have an app”.
For us, it was “learn once, write anywhere” for react, or “write once and actually use everywhere” for Flutter. Native wasn’t even a question for the size of the team on this latest project.
We make money by solving problems; not launching some app built with some language
I would note that trying to write an app at this point without UIKit to fill in the holes that SwiftUI currently has would be foolhardy.
How does Flutter compare to React Native? I haven’t used either but previously my go to framework was React Native since I have a ton of JS experience.
My React Native experience is very limited, but RN lacks of widgets. With Flutter you get complete package of material and apple widgets to create UI. Also RN is quite laggy on Android
Outside of flutter, how it's darts performance compared to other languages?
I find Flutter and Dart horrendous for apps. So many lines of code, so many things to check. I much preffer Swift approach or web approach is way more interesting.
How's xamarin? Anybody with experience here?
Buggy and unstable. I spent quite some time investigating Xamarin vs Flutter for my app, and ended up choosing Flutter simply because Xamarin was so unreliable.
No regrets whatsoever. There's no two ways about it - Flutter has already won the battle.
In fact, it hasn't just won the battle, it's already sitting in a spa celebrating its victory with bottles of champagne.
No regrets whatsoever. There's no two ways about it - Flutter has already won the battle.
In fact, it hasn't just won the battle, it's already sitting in a spa celebrating its victory with bottles of champagne.
I had an opposite experience with Xamarin.Forms - I loved my time with it. A deployed commercial app I made is in the stores for a year now.
No idea about Flutter though.
No idea about Flutter though.
Let me guess, using Xamarin from Mac.
Use it quite often and enjoy it. Biggest reason is because I love C#/.net. Only recently been using Xamarin.Forms, which seems to finally be getting to a pretty mature state. They’ve made it a lot easier to jump in/out of Xamarin.Forms and Xamarin native within the same app. Also recently added Hot-reload features to compete with flutter.
However, Flutter feels like it’s ultimately going to take over this space for “native” cross platform development. More momentum and less baggage. I have noticed Xamarin seems to be better about incorporating community feedback since flutter became its primary competition. Flex layout, Shell/route based navigation, etc. seem like responses to flutter features. Xamarin is great for C# fans but probably won’t win over many others outside of that with flutter as the alternative.
Haven’t used it myself, but a dev I really respect loves it. With better handling of null in v. 8, C# is legitimately one of he best mainstream languages.
This is a garbage software. I wasted 2 hrs installing / reinstalling this trash and it was complaining about licenses.
Untested unstable software... Never going anywhere near this pile of shit.
Untested unstable software... Never going anywhere near this pile of shit.
I am unfairly getting downvoted. I downloaded and installed this software and spent hours to fix the errors.
Running flutter doctor is recommended in their "Getting Started" page to check the sanity of the install.
But I kept getting the same "license status unknown" error after multiple installs /uninstalls in various order.
Their GitHub issues page has this issue as closed.
If this is the state of a simple install I dread to venture any further into actual development.
This will be a complete waste of developer's time and resources.
I am merely sharing my experience. Do not waste your time trying the flutter / stutter / sputter.
Running flutter doctor is recommended in their "Getting Started" page to check the sanity of the install.
But I kept getting the same "license status unknown" error after multiple installs /uninstalls in various order.
Their GitHub issues page has this issue as closed.
If this is the state of a simple install I dread to venture any further into actual development.
This will be a complete waste of developer's time and resources.
I am merely sharing my experience. Do not waste your time trying the flutter / stutter / sputter.
If you're running windows, someone found this worked and allows them to run
flutter doctor --android-licenses
https://github.com/flutter/flutter/issues/16025#issuecomment...
If you just want to try out flutter, I wonder if you can avoid the android stuff by just running on ios and when they are ready the desktop and the web.
flutter doctor --android-licenses
https://github.com/flutter/flutter/issues/16025#issuecomment...
If you just want to try out flutter, I wonder if you can avoid the android stuff by just running on ios and when they are ready the desktop and the web.
Thanks for your response.
Unfortunately, that solution is a dud. It does not work.
flutter doctor is looking for the sdkmanager in an outdated directory.
The point is not "googling" for fixes, the point is this software is not a well maintained software if I have to spend hours to just "Get started..."
Developers, abandon this piece of crap.
Android sdkmanager tool not found (%LOCALAPPDATA%\Android\Sdk\tools\bin\sdkmanager). Try re-installing or updating your Android SDK, visit https://flutter.dev/setup/#android-setup for detailed instructions.
Unfortunately, that solution is a dud. It does not work.
flutter doctor is looking for the sdkmanager in an outdated directory.
The point is not "googling" for fixes, the point is this software is not a well maintained software if I have to spend hours to just "Get started..."
Developers, abandon this piece of crap.
Android sdkmanager tool not found (%LOCALAPPDATA%\Android\Sdk\tools\bin\sdkmanager). Try re-installing or updating your Android SDK, visit https://flutter.dev/setup/#android-setup for detailed instructions.
Dart
- Is dynamically typed at the core
- Has no support for nullability
- Has old school syntax for constructors, semi colons
In other words, Dart on the wrong side of history for pretty much every single important feature for programming languages in 2020.
Even C# looks more modern than Dart from a design perspective, and C# is fifteen years old.
- Is dynamically typed at the core
- Has no support for nullability
- Has old school syntax for constructors, semi colons
In other words, Dart on the wrong side of history for pretty much every single important feature for programming languages in 2020.
Even C# looks more modern than Dart from a design perspective, and C# is fifteen years old.
- Dart 2 has a sound type system and the compiler has been receiving lots of optimisations based on types since then (several years now). So this is no longer true.
- that's currently true but in the next release (at least that's what the Dart team have been working on for the past several months) it will have nullable types just like Kotlin.
- That's a strange criticism. Dart has excellent constructor syntax, I don't know a language that is more flexible with constructors.
e.g.
- that's currently true but in the next release (at least that's what the Dart team have been working on for the past several months) it will have nullable types just like Kotlin.
- That's a strange criticism. Dart has excellent constructor syntax, I don't know a language that is more flexible with constructors.
e.g.
class Person {
String name;
int age;
Person(this.name, this.age);
String toString() => "Person($name, $age)";
}
main() => print(Person("Joe", 40));
Dart has some annoying traits that hurt productivity with it. For example, the lack of union types or some kind of sealed classes is fairly annoying when the language is actually statically typed.
There's some work being done to overcome this but so far no solution has seen the daylight in practice.
There's some work being done to overcome this but so far no solution has seen the daylight in practice.
Relax, it's being speced now, give them time to make non-nullables first.
The fun starts when you want to have final field that needs to be calculated in the constructor.
So do that in the initializer list?
If they had figured out a way to make Flutter use Kotlin back in 2015 before Android officially adopted it, I think it would have gained much more developer adoption.
I don't think Kotlin is performant enough for Flutter though.
I don't think Kotlin is performant enough for Flutter though.
The hard work is done by Skia, implemented in C++.
ART is able to do several nice optimizations, including vector instructions, and uses a mix of JIT/AOT with PGO.
Kotlin is performance enough, hence Jetpack Composer.
ART is able to do several nice optimizations, including vector instructions, and uses a mix of JIT/AOT with PGO.
Kotlin is performance enough, hence Jetpack Composer.
At the time (and to a large extent even now) Kotlin would have required shipping a JVM along (on non-Android platforms at least, and not a straightforward task at all on iOS).
That's _far_ from performant for the use case in question.
That's _far_ from performant for the use case in question.
As if Dart doesn't ship a runtime into all the platforms it runs on.
A quite big one actually.
That has nothing to do with performance, and plenty to do with storage space and download times, as anyone knowledgable how compilers work is well aware of.
A quite big one actually.
That has nothing to do with performance, and plenty to do with storage space and download times, as anyone knowledgable how compilers work is well aware of.
> As if Dart doesn't ship a runtime into all the platforms it runs on.
> A quite big one actually.
yeah, whole 4,5 mb....
yeah, whole 4,5 mb....
Do you _really_ want to compare the size on disk and [default] memory requirements of, say, HotSpot to the Dart AOT runtime?
Yes, specially because we aren't speaking about Hotspot here, rather ART, Kotlin/Native.
- rather ART
Is Android-specific, created specifically for Android, and it's almost as if the aim here was to develop a cross-platform framework that could at least target the two major mobile OSes in existence, one of which ships with literally zero Java anything. I brought up HotSpot because that's (part of) the canonical, actually-built-to-run-on-multiple-platforms JRE.
- Kotlin/Native
The state of Kotlin/Native is _far_ shabbier than the state of AOT-compiled Dart, and that's in 2020 (not, you know, 2014 when Flutter (then Sky) initially kicked off). It's interesting to me how in discussions like this people act as though the development of the project in question started literally yesterday.
Is Android-specific, created specifically for Android, and it's almost as if the aim here was to develop a cross-platform framework that could at least target the two major mobile OSes in existence, one of which ships with literally zero Java anything. I brought up HotSpot because that's (part of) the canonical, actually-built-to-run-on-multiple-platforms JRE.
- Kotlin/Native
The state of Kotlin/Native is _far_ shabbier than the state of AOT-compiled Dart, and that's in 2020 (not, you know, 2014 when Flutter (then Sky) initially kicked off). It's interesting to me how in discussions like this people act as though the development of the project in question started literally yesterday.
If Fuchsia never gets out the door, Dart is guaranteed to be another CoffeeScript.
I guess the lack of mature libraries and integration issues with Android native APIs is one reason why we consider it a language started yesterday.
I guess the lack of mature libraries and integration issues with Android native APIs is one reason why we consider it a language started yesterday.
When I refer to a project starting yesterday, in case it was too difficult to understand, I was implicitly asking you for non-posthoc justifications for choosing Kotlin _in 2014_ to build a UI framework that
- should target multiple mobile and desktop platforms (and not, like you seem to think, Android first or alone)
- is a game engine style, Skia-backed project, which you are essentially trying to pick a scripting language for.
So, do you actually have anything to back up Dart's runtime being a worse investment than your proposed ideas (which seem to be "go the way of Multi-OS Engine, that notoriously successful project" and/or "wait half a decade more for AOT compilation that would still be in beta and in a worse state than what we already have")?
- should target multiple mobile and desktop platforms (and not, like you seem to think, Android first or alone)
- is a game engine style, Skia-backed project, which you are essentially trying to pick a scripting language for.
So, do you actually have anything to back up Dart's runtime being a worse investment than your proposed ideas (which seem to be "go the way of Multi-OS Engine, that notoriously successful project" and/or "wait half a decade more for AOT compilation that would still be in beta and in a worse state than what we already have")?
Okay, so what does that have to do with Kotlin being an even worse choice I
And you weren't counting the matury of the eco-system.
But I think keeping in sync changes in API, hardware device drivers and new interactions across different platforms and device will still be nightmare and in general it will play catch up with native. It can be seen in the number of issues opened on flutter project on GitHub [1]. Hopefully there is some support from different platforms so it remains reasonable choice and perform well compared to native.
Also it’s declarative UI paradigm is good and even SwiftUI is doing the same.
I had concern about this project earlier although personally I looked at Dart just because it’s developed by Lara Bak the person who transformed google by giving them V8 engine in chrome. Earlier dart could not take off because no one wants dartvm in browsers except chrome.
It might not have succeeded in replacing JS from browser but Flutter is dart’s killer platform and it is very much focused now on becoming a language focused on user interface programming. So I think dart will survive beyond google.
[1] https://github.com/flutter/flutter/issues