I spent quite a few months comparing this with React Native.
Flutter has done cross-platform right. And it's somewhat sad and counter-intuitive but pretending to be native is a lot better than actually being native. iOS and Android are just too dissimilar in areas to provide a common layer on top of. In particular routing which is a mess with React Native.
Flutter also has the best development experience period. Nothing comes close. Compilation is fast. The reload cycle is instant. The tooling is excellent. It is really polished.
I just wish it had not come from Google because you always get that niggling feeling like it's going to abandoned. Which would be a real shame.
Thanks for the kind comments! I'm one of the product managers on the Flutter team, so you're welcome to apply suitable skepticism to anything I might say in response to your last point, but I will say that Flutter is already being used in many strategic projects here at Google, as well as for many customer apps, some of which already have tens of millions of users. For example, Alibaba are using it to build one of their big apps: https://www.youtube.com/watch?v=jtYk3gWRSw0
I don't know if this is helpful in assuaging your concerns?
Hey, thanks for the data point. I'm actually fairly interested in Flutter, but I have no interest at all in Dart since I find it severely lacking compared to modern, more popular production languages for mobile development such as TypeScript or Kotlin (which have features such as algebraic data types which have become an absolute must-have for me and my team), to the point it completely deters me from adopting it.
Is there any chance that the Flutter core could get bindings to another language in the future? Regardless, thank you for your work on Flutter; if not Flutter, at least it has paved the way for demonstrating a "native-imitation" makes a lot of sense with regards to developer productivity and performance, something that sorely needed more buy-in from the mobile community.
The great development experience is largely tied into Dart and it's toolchain, not to mention all of the underlying Dart code in the project. However, you can get the same kind of control flow out of Dart albeit with a little less static checking (https://github.com/dart-lang/sdk/issues/33079) so from a pragmatic standpoint this really shouldn't be something that's holding you back. The cost of not having ADTs is much lower than the cost of maintaining two separate iOS and Android apps (or even dealing with the downsides of other cross platform approaches IMO).
Hi. Thanks for the workaround, it's fairly similar to how it's handled in TS, except more verbose (which TS is already very much so when compared to something like Elm). That isn't a problem for me since I have some experience with functional programming, but that'll likely be a serious disincentive for other devs (TS itself has been a problem already). Maybe I'm off the mark and that is idiomatic and a very common Dart pattern, and can be assimilated through familiarity?
On another note, is there any workaround to have true non-nullable types?
As far as the cost of having one codebase goes, right now it's somewhat of a worse is better approach; we're looking into something that heavily improves things and is worth rewriting our apps into. RN hasn't been it due to its FFI/bridge problems not making us comfortable and Flutter is something we've been looking into but the language has been a deterrant, so it's hard for us to argue "yes it's better on every metric and worth the effort".
Dart has had some null-aware operators for awhile (https://news.dartlang.org/2015/08/dart-112-released-with-nul...) otherwise you'll need to explicitly do null checks. It's certainly not perfect, but it's still "good enough" to make handling null relatively concise. In my experience code review can do a good enough job at promoting good practices around null handling that non-nullable types are really just a "nice to have".
Please feel free to contribute here! That said, it's certainly possible to work around these things. Dart has a tuple library (https://github.com/dart-lang/tuple) which covers a lot, and much of what you'd use Unions for can still be covered by accepting `Object` or `dynamic` parameter types and doing some typechecking.
But it's a false premise. It seems like petting a dog on the way to the vet. The petting just calms the dog down, but has no effect on the inevitability of his situation.
So what value is a useless and pointless gesture that appears to be a marketing/public relations tactic?
Add null type annotation support to the big missing feature list. At this point every major mobile development language has nullability support, including plain old java.
I think nullability annotations have been the one major feature that have reduced crashes in the mobile apps I've worked on, and I've worked on some huge ones.
Seconded about the development experience. I wrote the same app in native Swift/Java, Flutter, and React Native. I did Flutter last, and even though I had never written a line of dart in my life, everything almost just worked.
There are still some really weird problems that occur, but after fixing those with `flutter clean`, it's hands down the best experience I've ever had making a mobile app.
If it were a google product, I wouldn’t trust it for a second. It seems that very few consumer facing products from Google are safe from being cut these days.
If google is using it internally, the risks change. After the Angular 2.0 debacle I’d fear Google Just up and changing everything and not providing a smooth migration pathway because they can. They probably won’t cut it, but that doesn’t mean that they won’t inadvertently hurt you really badly
From a marketing perspective, that was an awful choice. Releasing an effectively unrelated product and calling it 2.0 is just asking for trouble.
Second, they immediately announced no migration path and no more bug fixes at the same time. I’m not sure if they stuck with that, I was in the backbone camp at that time, but that is a painful pill to swallow. That they made that call without considering the downstream pain is a sign to me that I should be wary about depending on them
Angular 2 was released in Sep 2016. AngularJS continued releases up until Jul 2018, with 3 years of security fixes after that. 5 years is plenty of time to rewrite your app.
Either they backed down, or my memory is faulty. I recall at the time the announcement was that they were doing a hard cutover support wise. But since I wasn’t developing in Angular it was more of an interesting thing and not an immediate concern.
There is a large and growing team supporting Flutter at Google. Flutter is here to stay, and even beyond Google's investment in it there's a large number of dedicated community contributors too!
Almost everyone here talks about abandonment. It's become a sad Google reality, but I'd hazard that some people are posting from Google Chrome, which would defeat the point about worrying.
I use Flutter, I've released an app that's been in prod for about 5 months now. Flutter runs on Dart, which is a Google-bred language. From my little knowledge, most/some of the people working on Dart are the team in Aarhus that work(ed) on V8. Our Vyacheslav Egorov (mraleph) being first that comes to mind.
Is Google going to abandon Flutter, what about Dart? Should I not learn Go because they'll also abandon it? Heck, should I not develop for Android because they'll abandon it too?
The fearmongering is a bit excessive. I'd think Google has a better track record with software platforms. I separate Google into:
- Products - come for free, can be abandoned any time
- APIs - come for free, don't build your business around them in case MapsGate price surges come your way. Or, if you rely on them out of being "free", always have contingency plans to switch. After all, if they build a market then destroy it, it's a good space for smaller players to join in.
Flutter allowed me to do in a few days what Java/Kotlin was taking me weeks. Why? It makes developing UIs much easier. As one can see from the RP2 announcement, background execution looks hairy, app size is improved but the build process still lacks what native has (e.g. updates to an app result in user downloading whole apk).
Will I have to rewrite my app again when Flutter is abandoned? Sure, but it won't be an overnight rewrite. I'll probably be able to get away with a 1-2 year window (if I need one) before the last supported Google Play Services becomes obsolete.
For me, I'm willing to take that upfront benefit. Yes, downside's learning yet another new language. I learnt Dart, and it was about 80% similar to the langs that I already know.
> but I'd hazard that some people are posting from Google Chrome, which would defeat the point about worrying.
Uhhh, how do you draw that conclusion? There are lots of browsers and they take literally zero time to learn. Comparing a browser to programming language or framework is apples and oranges.
> Is Google going to abandon Flutter, what about Dart? Should I not learn Go because they'll also abandon it? Heck, should I not develop for Android because they'll abandon it too?
I have been a strict Android user for years. Google has effectively abandoned it with the way they've managed the project. I am moving to iOS for a variety of reasons, one of which is that I know where they (Apple) stand with the platform.
I wouldn't learn Go or Kotlin either, honestly, as there are arguably lots of languages that do the same with less separation anxiety.
My only mobile apps are Android only and regret it. I was a big android advocate and now I am not. I have been excited too many times and let down too many times to really care at this point. Google really wasted a lot of my time in retrospect. They announced projects like they are the second coming only to kill them once you have invested countless hours of time learning. I still have the OG Android ADK from I/o 2011...
Both skills much more useful on contexts outside Android development.
If I would need to write cross platform mobile apps production code, I would rather go C++ for business logic with native views, Qt, Xamarin or if performance requirements aren't tight, PWAs.
Dart makes it unattractive to learn Flutter, given its past history.
And Kotlin it remains to be seen how well it will faire in the actual Java world, outside Android, where we can make use of the latest versions slowly picking features from the alternative languages.
> Uhhh, how do you draw that conclusion? There are lots of browsers and they take literally zero time to learn. Comparing a browser to programming language or framework is apples and oranges.
So, Google just released a new pineapple, but because they tend to kill the orange trees, I'd rather not bother with the pineapple. Google Chrome is a Google product. A general fear/hesitance of using Google products should apply similarly to Chrome. Otherwise you're only validating my point.
> Google has effectively abandoned it with the way they've managed the project.
Our opinions differ, which is fine. I'll leave it there.
> I wouldn't learn Go or Kotlin either, honestly, as there are arguably lots of languages that do the same with less separation anxiety.
That's fair, there's lots of languages that do a lot of things. I often learn new languages because of promises to solve some existing pain points. Separation anxiety differs from person to person, and one has to weigh costs and benefits.
The migration from Chrome to Firefox takes between 30 seconds and 30 minutes, depending on how much stuff you choose to move over, and has nothing to do with migrating code between two platforms. It's not a fair comparison unless you're talking about developing browser extensions, and even then the API is very close to being cross-platform[0].
I don't think most people are making a principled stand against the use of Google products, they're just instinctively performing a risk analysis.
But that's my point (which other people are making). There's a difference between Google APIs, products and software platforms. Some are riskier than not.
It adds little to the conversation if someone just says "scared of abandonment" without providing more context. Yes, one's entitled to that opinion, but it's slightly misplaced sentiment.
Out of interest, how long would it take for one to migrate from Go to say C or Java (if Go is killed)? Similarly, how long to go from some Google cloud service to either another provider or a different other service?
I agree with you about instinctively performing a risk analysis, but was offering a different perspective that perhaps one should separate Google into a few categories, then make judgement per category.
> Yes, one's entitled to that opinion, but it's slightly misplaced sentiment.
How do you figure? How long have you been using/developing with Google products?
Microsoft had the same reputation a few years ago. They learned the hard way what happens when you piss off developers. They are now making great strides to right those wrongs. What is Google doing to assuage those fears?
The way they have managed Android itself should give all mobile developers some consternation. It is an absolute mess with a ridiculous amount of cognitive overhead. Its a utility OS now and a really bad one at that.
My gut tells me that Android will be abandoned soon. Samsung could kill Android if it wanted to...
From this and your other reply, you seem to have been burnt by something in Android.
The mobile market for which I develop products is made up of over 80% Android. Whether Sundar Pichai decides to kill Android tomorrow or now, I'm not going to let that get in the way of me making a living from a platform that currently exists with a significant market share re. my target market.
Android APIs get partially rebooted at every Google IO, and the NDK is what it is, no need to add extra immature tooling into the mix, which isn't even officially endorsed by the Android team.
In that regard one is safer (CV) using Qt or Xamarin, given JavaScript, C++, C# and F#.
I haven't tried Flutter yet, but I want to provide my experience of what non-native mobile development usually looks like comparing to native. Through my mobile development career I have tried C/C++ cross-platform development on mobile, JavaScript frameworks (e.g. PhoneGap), Xamarin and React Native.
Cross-platform frameworks always seem attractive because you can write code once and run it on both Android and iOS. When you start development it might also feel productive at first because you finish 80% of the project much faster than with using native platform frameworks. Problems begin when you need to interface with native code or if there are some small annoying issues. You get stuck for hours and days trying to solve something that would take much less if you dealt with native platform SDK. In the end you are not completely satisfied with your hacky solution and it took as much time as native app would take.
My opinion is that if you have a very simple app, it might be OK to write it in, for example, React Native of Flutter. But if you have a more complicated app and it's an important part of your business, you should go native.
Yes, that was my conclusion a few months ago. I'm currently working on an Android app, and even though I published the Flutter app in "record time", the drawback is the amount of mental energy needed to make certain platform tasks work.
Background execution was the biggest for me, I didn't want to write a Flutter plugin that interacts with a background service (because even though that's now possible, it still feels confusing to me).
Simple(r) app, Flutter's very good at that. I'll see what happens post 1.0
I first started developing with Flutter about a year ago.
One thing that has really impressed me is how responsive the Flutter team is to developers. Often when I posted a question on Stack Overflow it would be answered perfectly within 24 hours by a member of the Flutter team.
Contrast this with React Native where Facebook's attitude seems to be to develop what they need themselves then 'throw it over the wall' to for others to improve.
The Flutter team is like a dog that really wants you to be happy. The React Native team is like a cat that doesn't really care about you as long as she gets fed.
There is also an effort to bring flutter on the desktop.
I dabbled (briefly) in it, got flutter app running on windows + linux, though certain integration factors (smooth window resizing, stability, mouse wheel support, etc.) were not there yet.
For some of them (mouse wheel, keyboard, tabbing) there might be more work needed (and maybe not seen as important), but it could bring a real "electron" killer, where my slack, teams or whatever else "electron" app does not spawn 5 processes, and take GB of memory (granted, flutter still takes a lot, compared to leaner Qt, and much much leaner write directly using Win32), but then there are some sensible limits, and going below these (for the sake of perfection) doesn't buy you much nowadays (I no longer have to run QuarterDeck QEMM to shuffle my 640kb DOS+EMS memory efficiently around :))
(Disclosure: I'm the Eng. Mgr for the Flutter project at Google.)
I've seen Flutter run in lots of places, including desktops. Desktop isn't something my team is actively developing at this time (we're very focused on making mobile awesome), but we're definitely not stopping others from doing so. There is even another team at Google experimenting with the idea:
Thank you so much for the work on the language/platform. I used to work for Google (LAX), and our team was using GWT, hopefully they have transitioned to Dart + Angular (by now). I fell in love with Flutter right away, but it was in no way connected to what I did back there.
I was able to get the gallery on, had to do some tweaks (like enforce binary mode when reading files, and certain other things, but haven't looked since then).
We're using it to replace our native iOS and Android apps enabling us to have a single code base. This is critical for a team as small as ours (2 devs covering web and mobile).
I can't sing its praises strongly enough, you can check out the code for our app here:
I am moving away from Google as fast as I can in most areas. Every time I bird-dog one of their products I am ultimately let down. There is no way I can trust anything they build at this point. I wish it were different as they have some really good ideas, they are just the worst when it comes to follow through for the long haul.
Are you frustrated with the way Android apps are developed? Tired of amount of time to get simple list working? Writing lot of boiler plate code only to update list from a dialog box? Ever got scared of implementing a navigation drawer or a fragment? Did you left Android development because the time and code to implement it was way greater than expected? Tired of handling life cycles?
Sorry for being dramatic but if you answered yes to any of those give a try to Flutter! You will be surprised of how fast you can develop an app for mobile with descent UI. Thank me later!
Flutter's edge over these technologies is faster development cycles (very fast build times, sub-second reloading without losing state, very rapid ability to update code/GUI after deployment to a testing device, and very fast render times).
Xamarin and Qt are fine products, and I know Xamarin has been working on some improvements over deploy times, but it still can't touch what Flutter does there. And if you know C++ and C# already, Dart is a breeze.
Why do they want me to learn a new language to make use of a gui runtime+lib? Seriously. What makes that language that revolutionary so that nothing else, no other tried & tested & loathed language, could have been used instead? I don't see it.
It's not easy to explain in a HN comment. Technical decisions like these never are. In this particular case, there is no single "Dart can do X and nothing else can". That's not true for any feature. It's the combination that mattered.
All in all, Dart was a really, really, really good choice. Not from a marketing perspective, obviously, but that's not everything.
So, the argument basically boils down to: It's a bad thing to use a dsl or similar only for gui. It's a good thing to use a whole new language you have to port all your code to and that has only a small ecosystem so you can also write all these libraries yourself.
Don't get me wrong. Flutter may well be a formidable piece of software. Dart either. I just don't get how flutter is marketed around the fact that dart was there first with no convincing use case and that people only then started looking for a raison d'etre.
Hey I've been following Dartlang's up and downs over the years, here are some ramblings about Flutter.
When the chrome guys started the Sky experiment, now the flutter project, they started with javascript. I don't know why they dropped javascript, but they looked at several languages before trying Dart. Here is a floss weekly episode with one of the co-founders, talks about flutter's hotreload, an idea that came from the Dart team.
If swift was opensource back then they may have gone with it and if they started today they may have gone with kotlin native.
Flutter's hotreload feature, something that they didn't know they wanted, was created after they decided to give Dart a go. While the Dart team had missed the boat on getting the Dart VM into chrome, they still had their internal customers using Dart2JS. The Dart team also had their own experiments in IOT and running on IOS.
Maybe Sky/Flutter guys saw Dart solving their problems that Javascript couldn't and they also saw that the Dart team has the expertise to help them in advancing their experiment to where it is today.
Hi there, Dart is a really versatile language for our needs: it's what powers stateful Hot Reload, for instance, because it has a powerful VM and JIT compiler that work really well for debug purposes, but also compiles natively to ARM code that runs on both iOS and Android. That combination is pretty compelling, and also hard to find in other languages. Dart also compiles to JavaScript, so you can use the same business logic for your web apps.
Honestly, the language itself is easy to learn if you come from a managed code background -- as ever, it's the domain knowledge that takes time to build (e.g. the libraries and framework of components and classes that any complex application takes advantage of).
Dart 2.0 is not Dart 1.0. And the Flutter team has had a large hand in shaping and forming Dart to its current state (and continues to drive certain priorities for it).
Dart is easy to learn (espeically if you come from a JavaScript, Java, or C# background). It can be compiled in ways suitable for distribution in both Apple and Play Stores. And the Flutter team has direct access to the language team behind Dart to ensure that it works well for mobile development.
Across several industries and in different companies, my experience was that learning Dart was measured in hours and not weeks. One company started to train their HR employees to code in Dart (being their first programming language that they learn) in order to streamline the interviewing process of developers.
If you have seen C#, Kotlin, TypeScript or Java code and understand it, you will understand Dart and will be able to use the language soon enough.
About two and half years ago I've been using Dart as an interview language for several companies (even though their stack did not include it). Except for one python shop (who were really looking for a hard-core python dev), everyone else was happy with my solutions presented in Dart, because ultimately: (1) the skill in one language is transferable to another one, (2) the job is rarely about
a specific technology, rather about seeking a solution.
It usually starts with a small, new thing to adopt a new tech (e.g. a not-yet-important mobile app, or a medium-sized single-page web app), and eventually it can take over other parts of the stack. How fast it happens is really unpredictable.
I agree that Flutter would have been better off using a popular language like Swift or Kotlin.
However, it really isn't a difficult language to pick up. I ported a Java app to Flutter and it was mostly just a case of copying the class files and fixing the syntax errors.
You can say the same thing about Objective-C. Without Kotlin Native, there hasn't been any non-Android use cases for the language yet. Even Swift's web and ML applications haven't gotten huge traction either.
Flutter might be a cool project, but what's the status of integrating native controls?
Mobile apps are not only CRUD clients and do lots of stuff that needs tight OS integration. The last time I checked, flutter couldn't do Maps, GeoLocations, AR (ArKit/ARCore), Encryption, audio/video, file storage etc activities that are outside the normal purview of a CRUD TableView App.
Since flutter team seems to be active here, could anyone from the team shed light on these aspects?
(Disclosure: I'm the Eng. Mgr for the Flutter project at Google.)
In general Flutter takes the position that Flutter should not limit your choices and your apps should be able to do anything the phone can do. Flutter apps are just iOS or Android apps, you can always open up the ios or android sub-folders and write as much Obj-C/Swift or Java/Kotlin code as you like.
Showing arbitrary native views inline with other Flutter content is actively in progress: https://github.com/flutter/flutter/issues/19030 (already possible to show views to the side of/on-top-of a FlutterView of course).
AR is not something I've seen any work on yet, but it's always possible to throw up a full-screen ARKit/ARCore view using ObjC/Java your otherwise-Flutter-built app.
Flutter includes BoringSSL as part of it's runtime, some encryption APIs are exposed, there is probably more for us to do here. There is also pure-Dart crypto, e.g. https://pub.dartlang.org/packages/crypto and of course always possible to write your own wrappers around iOS/Android APIs (which someone may already have done too).
Thanks for response, I have high hopes from Flutter, however having spend years in cross-platform mobile development, I just want to avoid the most common pitfalls. I hope this comment doesn't come out as snarky, I just wanted to give an honest opinion.
Not having first-class Maps is a deal breaker for many apps, and having only Google Maps support is not what most developers want. I would like to port my current app, but without proper maps support Flutter feels like a cousin of Ionic.
What's the FFI story of Flutter? Could you please point me to the direction of using ARkit view using ObjC/Java FFI? From what I've seen we've to wire an OpenGL View to achieve AR capabilities, but I might be wrong.
While the crypto package is a good start, I was more interested in having access to the Trusted Execution Environment (TEE) on iOS/Android. Do you have any work being done in that area? Lots of apps (e.g. Fintech) have security audits and these things could be a deal breaker.
A cursory look the Audio plugins show that it's a wrapper around AVFoundation etc. and they are capable of playing audio/video, I would love to see an official plugin with 1-to-1 feature parity with iOS/Android AV API.
Flutter is a great project, but it seems to be plagued by the same issues that React Native, and Xamarin has.
I've found that if you are using an older phone then you will certainly notice that Flutter is not as smooth as a native app. However, I know the Flutter team have made a lot of progress with performance so it may not be so bad.
Are those SO popularity comparison numbers real? If they are, I feel they were somehow artificially inflated. I have nothing against Flutter, but I don't think at this point it's as widely used as Xamarin and React Native. For Angular numbers should be even higher.
That is, Flutter is shooting up and overtaking Xamarin but still only half the popularity of React Native. This also roughly correlates with mentions on Google Trends:
On job websites React Native is way ahead - which you would expect given React Native's headstart. For example, www.jobstreet.co.id currently has 43 jobs for "React Native" but only 5 for "Flutter".
Hi there, the source for these numbers is the StackOverflow API. Just to clarify, the chart we have in the blog is showing question _views_, not questions tagged. There are more questions for other frameworks still (since they're more mature technologies), but we're seeing lots of views of questions tagged with Flutter.
I am especially nervous about Flutter since they don't even have to abandon it. If they don't keep pace with new OS releases, there is no great way to recoup your investment in Flutter. You are just stuck without an outdated looking app or forced to do a full rewrite in the native frameworks.
Keep in mind that Flutter is an open-source project with an active community. There's nothing particularly special about the built-in widgets that the Flutter framework provides; other developers can make and publish their own widgets easily enough if the built-in widgets are insufficient.
Was Wave a product or a technology? Both, I guess.
That said, Wave doesn't seem comparable. Maybe GWT? If so, I'd be perfectly happy if Flutter has the lifespan of GWT, which is some 12 years old now and still viable (if perhaps a little crusty). 12 years is a phenomenal run for a piece of frontend tech.
I'm not completely sure what the difference between a technology and a product is, but I think it was a product, because it was SaaS with only one provider and closed source until the shutdown announcement, and very few developers were integrating with it. Only when the shutdown was announced did they open source it, and it became more of a technology than a product.
I think the Android userspace might count as a technology that's been shut down. When Android first came out, it looked a lot like a mobile counterpart to a Linux distro with Gnome or KDE, with built in simple open source apps, like music, photos, downloads, and notes (now Keep). Now all these apps are littered with tie-ins to Google, and Samsung and Huawei have gone off and developed alternatives because it's annoying to use these apps without fully buying into Google (same to a lesser extent for Maps and Chrome). This might be a stretch though, and besides this I don't know of any Google technology that was popular and useful and got shut down in a way that reminds me of Google Reader.
Fabric had it coming. Twitter sold it because they no longer wanted to focus on it.
When Google bought it, it felt a lot like buying the market. What Fabric tools are you going to miss, which Firebase does not have/support?
It doesn't make sense for Google to maintain two platforms that do the same thing indefinitely.
Twitter didn't have viable alternatives. They could have sold it to someone else, but who?
- Apple? Forget about Android support
- Facebook? Not interested, they killed Parse
- Google? Made sense, because the value of Fabric was the number of devs using it.
Fabric Crash Analytics was a strong product, why not bring in the team that developed it to gradually bring its features into Firebase?
Fabric is not a good example; it wasn't "abandoned" as developers were given alternatives. It also works better for us developers, because now I don't have to bundle a Fabric SDK and a Firebase SDK.
Lastly, given that Twitter is shutting down access to third-parties to their API, the value of Fabric's integration with Twitter might have dwindled for some people.
I'm not too familiar with Fabric, but that sounds like it would count, because it was a technology that external developers were building on that got shut down without a clear migration path.
UIKit has been pretty much been the same thing for about 10+ years.
There are additions and tweaks here and there, but you can still make table views inside navigation controllers inside tab bar controllers using frame based layout with near identical code you would use in iOS 2.
Every year at Google IO Android APIs get partially rebooted, the NDK already got three build systems, Android Studio is being rebuilt from version to version.
Good luck to those that jump today into Android without the background how it grew up since the early days.
Documentation is outdated and many of the still documented best practices have long been replaced by Medium posts and SO answers about the new best practices that replaced them.
Yes, but they still manage to be more pleasant to work with than building UIs with <div> and CSS, while making it work across any device with something that resembles a browser on them.
This is something that makes google look better, because not only is it a tool that seems like it has enough momentum that it won't get abandoned, it also brings a forgotten Google product, the Dart programming language, back into the limelight.
Google is making a smart move by showcasing Flutter's capability to make iOS apps. Cross-platform SDKs have a tendency of favoring one (iOS with React Native) or neither. By showing that devs can easily make quality apps on iOS, they show the promise of Flutter.
It's really sad how Google can possibly (I won't bother wasting my time to find out) make something really truly awesome, and it just doesn't matter at all. Their brand has a stink to it that won't wear off any time soon, if ever.
They chose an evil path of manipulating users into giving up privacy. Talking out both sides of their mouth with politics and freedom of speech and other things. Creating and dumping tech like hot potatoes. Attempts at mass manipulation of the internet (AMP, messing with the location bar). The list goes on...
Google is schizophrenic, and I don't know if they can come back from this in the long term. I won't even bother looking at any of their tech anymore, there are plenty of great alternatives to every service they offer without all the Google baggage.
There really isn't an alternative for what Flutter does, which is high quality cross platform apps that don't require separate UI code. Xamarin has Forms, but the UX is not nearly at the level of what you get from Flutter, and it would require some serious rework of how they render their widgets for that to change. Other solutions like Qt are just lagging behind, as much as I wish that weren't the case. Ultimately I think Google has the ability to make Flutter the primary platform for developing mobile apps in the future, if they emphasize it as the preferred way of making new Android apps and especially if they make it relatively easy to integrate Flutter into existing native apps. If it were possible to easily drop one screen into an iOS and Android app with Flutter, this would start getting immediate adoption because of how much time and money it can save. Ultimately that matters a lot more than "Google baggage" that only a small fraction of developers really care about.
At one point there wasn't an alternative to Angular either, look what we have now. Not only that, there's still native. Which means anyone can easily hold out that is on the fence for who knows what comes in the future.
Principles matter at some level, which is why many businesses abandoned Godaddy a few years back. But also there's simple budget considerations. Google has cost us tons of money over the years adjusting to their services. Now we don't have to anymore, and it's a relief.
If I am forced to spend money I'd rather spend it on something competition than to bolstering a belligerent monopoly and also support a system that will still be around, or at the very least, give two craps about our situation.
Maybe you are too young to remember the bad old days with Microsoft was the mean kid on the block. Google is getting worse than Microsoft ever was. And that is really bad.
I'd argue people left GoDaddy because their services suck. At least, that's been my experience with them. And at the same time, what they were doing wasn't unique, you have nearly unlimited alternatives in that space. I hope you're right with the Angular comparison though, I would love to see other projects move in a direction that truly competes with what Flutter is doing. As for native...you're right, I'll continue to tolerate it because none of the cross platform solutions are really "there" yet, Flutter included at the moment. It's interesting from a technical perspective, but I wouldn't bet on it for a serious project until it at least hits 1.0
The specific instance related to Godaddy that was the straw that broke things was the SOPA fiasco. Google has done many similar things, it could be argued even far worse things, and it's somehow survived so far. But to think it's any better of a company is to be myopic.
Well, I am in no hurry with Flutter, we will see how things turn out in the next few years.
Looking at the new Cupertino stuff.... since Google is reimplementing all iOS animations for navigation, bounce, etc., is that not infringing on Apple's patents?
Nevercode is proud to join Flutter revolution! The day Flutter announces Release Preview 2 Nevercode CI/CD supports Flutter apps out-of-the-box. Building beautiful iOS & Android apps using a single code base just got better! Check our doc: https://developer.nevercode.io/docs/building-flutter-apps
Is Flutter using native controls here, or are they drawing a copy of them by hand? I didn’t see a scroll bar in that demo, so I’m not sure. The rest of the stuff looked pretty good, though of course I’d need to actually physically try it to give it a final opinion rather than just rely on a GIF of someone interacting with it.
Flutter takes full control of the rendering pipeline directly on both platforms - all the controls your seeing are written in Dart for Flutter, but designed to mimic the best of what the platform offers.
In particular, this means that if you're running an Android app on an older device, it can still show the latest Material design widgets (and similarly for iOS, showing the latest Cupertino styled widgets, or Material).
> Flutter takes full control of the rendering pipeline directly on both platforms - all the controls your seeing are written in Dart for Flutter, but designed to mimic the best of what the platform offers.
You see, this is rarely what I want. I’ve seen time and time again people trying to emulate controls and it just doesn’t work. Apple has a whole team that’s spent years making the iOS UI look just the way it is, and I don’t trust any other team to be able to copy this without serious effort. Sure, it might look pretty similar, but something always doesn’t work: the control behaves differently, isn’t accessible, animates incorrectly, etc.
I encourage you to compare our iOS ("cupertino") widgets with the UiKit ones. We've still got many to implement, but I think we have the fidelity pretty high for the ones we've implemented. If you disagree please do file bugs, we care very much about fidelity.
I hear you. I was suspicious of this too, but there's been a lot of work put into making the controls we design work well and properly implement accessibility/native platform behaviors. And when something is off, someone ends up raising an issue and it gets fixed.
It also makes it very easy for developers to create their own custom widgets/layouts that are pretty challenging to achieve in other platforms.
I hope you'll give it a try some time - if nothing else, you might be able to raise some issues to help us improve some of those details!
Any word on the testing situation? Currently, my inaugural app has a bunch of tests which won't run as a) you can't use plugins in unit tests, and b) integration tests (via flutter drive) won't work with platform channels, as it has a dependency on dart:ui.
Flutter has done cross-platform right. And it's somewhat sad and counter-intuitive but pretending to be native is a lot better than actually being native. iOS and Android are just too dissimilar in areas to provide a common layer on top of. In particular routing which is a mess with React Native.
Flutter also has the best development experience period. Nothing comes close. Compilation is fast. The reload cycle is instant. The tooling is excellent. It is really polished.
I just wish it had not come from Google because you always get that niggling feeling like it's going to abandoned. Which would be a real shame.