Announcing Flutter beta 1: Build beautiful native apps
developers.googleblog.com
developers.googleblog.com
Here's a completely new platform with a forward thinking, reactive UI model and fast but flexible language that offers a much less painful environment for us to live in day to day and all people can do is crap on it because it isn't JavaScript and they have to learn a new, very slightly unfamiliar language.
You can learn a lot about why programming is such a shit show by reading the comments on this one.
Dunning-Kruger is real.
For more information on what the hell happened in this thread: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Edit: Just to be clear, I'm referring to the same comments you are, not your comment. I'm amazed at how many people can just immediately dismiss this because it uses Dart while not even knowing much of anything about Dart.
I also can't respond to anything more yet beyond editing because I've been rate limited (for being an asshole, it was well deserved).
Is calling the Dunning-Kruger effect an example of the Dunning-Kruger effect?
Not implying anything, just curious indeed.
PS: And thanks for mentioning it!
It literally looks like astroturffing against dart as a language.
I think this awesome that, even though dart is seeing low adoption, Google is pushing forward and building flutter. The framework and language look like they have a lot of good technical reasons of existing, chief amongst which is native AOT compilation.
Best of luck to the team!
Could you please share more details?
* Ruby (coupled very strongly with Rails). Around 2007 in particular
* JavaScript when nodejs started becoming a thing, and microservices. The hype!
* Nim
* Clojure(script) went through it on HN, though I could see some of the reasons why it did (and it was muted)
* Can't speak about the functional languages as I've yet to grasp them.
Prepare for the ReasonML hype train though - which I am also on! :P
When Android came out, it was able to piggyback on millions of existing Java packages (such as Apache commons). When Kotlin came out, it was able to piggyback on millions of existing Java packages and Android packages (and even better, existing Java code can seamlessly forward work with Kotlin).
Now, Google is using its muscle to drag everyone to its language which has pretty much no existing adoption.
Oh. And many remember Dart being optional-typed (like Typescript).
But, when Go came out, there were no libraries. And it didn't get so much bad press.
1. Go had a lot going for it when it came out (single, static, exe, memory safety).
2. Go's stdlib came with a lot out of the box. To the extent that you can write some fairly complicated code without touching a single library.
3. There was cgo.
So? Some could argue it's a very productive approach.
Dynamically typed languages are a thing of the past.
I think it's a great middle ground between no type system and what Haskell and ML offer.
Sound type systems are pretty much unusable.
Some could. And others look at it and think "Python" or "JS" speed app. Oh. And harder to refactor/detect errors.
[1] https://www.dartlang.org/dart-2#strong-mode-and-static-typin...
So all old Dart code won't work now? This seems much worse than the Python 2 - Python 3 jump.
Yes, we are migrating to a new type system, previously called "strong mode". This is the main reason for the major version number bump to Dart 2.0.
> So all old Dart code won't work now?
Most Dart code works the same as it did before. A significant but relatively small amount will need a little love and migration to fix type errors. These are usually straightforward fixed.
We have a lot of experience migrating code like this (Google's internal corpus of Dart code is now using the new type system). If you are other users run into problems, we are happy to help.
Most external Dart users have already migrated their code to strong mode over the past year or two. It went as smoothly as you could hope and most of the feedback we got was really positive.
For me, one of the main pieces of evidence in favor of moving Dart from optional types to the new static type system was how easy this migration was (relatively speaking). I'd claimed years ago that most Dart users already wrote in a fairly static style, and this helped confirm that.
> This seems much worse than the Python 2 - Python 3 jump.
Oh, heavens no. Most of the pain in Python as I understand it is around strings. Between 2 and 3, Python changed the meaning and runtime behavior of an existing very commonly used type. That's basically the hardest possible change to do (though I understand why they made that change).
Dart's migration is more annoyingly in your face because it's tightening the static type system. Existing code may now have type errors and you have to fix them before the code can be compiled.
But on the other hand, the type system will basically tell you all the code you need to fix to complete the migration without having to run anything. There are few scary migration bugs hiding in your code that you won't discover until much later. Once your error window is empty, you're almost completely done.
And, in return, you get a much tighter static type system — a sound one, unlike, say, TypeScript — that finds more mistakes in your code than the old one did.
Though, to be fair, you'd have to do that even if the Flutter was written in Kotlin. Maybe not the back-end parts, but the View would definitely have to be re-written.
Is it like calling Java from Kotlin (pretty) or C from Java (ugly)?
> The other thing to consider is that this advantage of code reuse was never realized to iOS.
iOS does interact well with C.
You can call into Android libraries or SDK code from Java or Kotlin code via plugins on Android.
You can call into iOS libraries or SDK code from Objective-C or Swift (as of 12 days ago https://github.com/flutter/flutter/issues/10968) code via plugins on iOS.
It is high time we get over this ridiculous need that everything works with everything else without any added work. Writing software (for most) is a profession. You should expect to have to do actual work.
Here is how we make an HTTP request in react-native:
fetch('https://facebook.github.io/react-native/movies.json');
import 'dart:io';
var url = 'https://httpbin.org/ip';
var httpClient = new HttpClient();
await httpClient.getUrl(Uri.parse(url));
Sure, I could write a wrapper and create myself a helper method. So could 100,000 other developers. Why not just include first-class functionality out of the box? The further I go into Dart, the more I realize it's just a slimmer java. I don't want slimmer java, I want better javascript. (And don't go asking your most experienced, most technical developers what "Better" means. Go and ask the thousands of shitty developers who barely have a handle on it, my coworkers still have trouble with "this" for godsakes).
The world is an interconnected place these days. I am tempted to say that there are fewer apps that don't need HTTP than apps that do. Find me a top 10 app that doesn't make HTTP requests. Interconnectivity is where it's at right now, it's the internet.
Having said that, we definitely need to make Flutter's network story better. This isn't one of our near-term priorities, but medium term I plan to implement a library that abstracts away issues like unreliable networks, offline, etc, and has a very simple API.
No of course not, but let's not go down that road because Dart loses that battle too. With fetch, I just attach the .finally() callback and set my loading flag to false. It's one extra line. Showing an error state is also one extra line using .catch().
> we definitely need to make Flutter's network story better
You can try, but it'll just end up looking like fetch, it doesn't get any simpler than that. The fetch spec has been discussed on end, you're just going to have the same conversations they did.
And lo, when you have undergone all the work of making Flutter a first class package, you will step back and say "huh, our view layer looks just like HTML and CSS, and our logic looks just like JavaScript... we recreated Web!"
Your JS code isn't better at all. They're just as easy as eachother.
https://caniuse.com/#feat=fetch (87.35% of global browser have fetch)
import 'whatwg-fetch';
vs
import 'dart:io';
Doesn't seem very significant to me.
For example, whatever Google's new Fuchsia OS is going to run on, they use flutter. Is every app for the OS supposed to be written in Dart? If so screw that. It's been tried with Java (Android), Objective C (Apple), Swift (Apple), Javascript (Web), Visual Basic (not really, but MS). And while it's not always the only choice on a platform, each of these was the preferred language. People have to stop telling programmers what language to use. If you want to make yet another GUI toolkit then go right ahead, solve the issues that other toolkits had, but remember NOT being language agnostic has been an issue with many of them.
AFAIK, they already support Rust.
I found the development experience much smoother than react native, things just worked, whereas in react native there were many many small bugs and issues with the many packages required.
Flutter IDE support is good with the intellij plugin [1]. Performance, I didn't do any benchmarks, but a simple list with thousands of items feels much smoother on flutter than react native. There are packages for redux as well in flutter, so state management is taken care of [2]. The only downside I experienced with flutter is that Json handling is clumsy, apparently because flutter doesn't support reflection, which would be necessary to have comfortable Json-decoding like with Javas gson or go's json package [3].
Another thing to consider is that react native will render on one thread, and handle the application logic on another thread, but that means the application logic is still restricted to a single javascript thread, which can lead to bottlenecks eventually. From what I understand (haven't tested), dart can work multithreaded, having an advantages there.
End of the day, I would chose flutter over react native. Mainly because of Javascript and all the pain that comes with it.
[1] https://plugins.jetbrains.com/plugin/9212-flutter
How difficult it is to use a Java library from Dart?
The Flutter team has done an amazing job recreating Material and Cupertino (iOS) widgets, and I honestly can't tell the difference. Also, platform specific behaviors (e.g., the scroll bounce on iOS) are also preserved.
If you haven't seen a Flutter app in the wild, I'd highly recommend checking out the Gallery application on Google Play (https://play.google.com/store/apps/details?id=io.flutter.gal...). Here you can see all the available widgets for each platform and even toggle between iOS and Android behaviors.
If the development workflow is good, trying it on a smaller Android project seems feasible. What I find attractive there is that you can sidestep the legacy Android APIs which was created for much more constrained hardware than we run today. Might even be worth just doing that and keeping iOS development the same. If iOS 12 widgets all look different, that would age Flutter apps.
Uses custom rendering engine based on Skia.
Can write UX just once for all platforms if you don't mind fixing the widget set.
Custom widgets work on all supported platforms.
Can in theory be ported to Desktops also, assuming someone writes flutter engine bindings for Win/MacOS/Linux. If this occurs, then you will truly have a modern, cross-XP, write-once-run-anywhere, compile-to-pure-binary, reactive UX framework
Not a JS framework (tm)
Xamarin currently manipulates OEM SDKs's bundled widgets https://visualstudiomagazine.com/articles/2017/12/04/flutter...
Though there is a proof of concept running Xamarin with portable custom widgets on Skia https://xamarinhelp.com/skixam-skiasharp-platform-xamarin-fo...
Whenever something promises this, it usually only works kinda well on it's "home" or "main" platform, and runs crappy everywhere else.
That's a bit inflammatory, but in my opinion it's true. Qt, and SWT applications look... off... in many ways, they feel wrong, and often times it gets in the way (like not using a native file picker widget from the OS).
They can be made to work well on most platforms, but it takes a LOT of work.
Android users don't expect Android interfaces to work like iPhone interfaces and visa-versa. You can do all the skinning in the world but the underlying workflow of the interface won't match the platform.
At the bare minimum, you need to use the native widgets on each OS.
It's baffling to me that Flutter didn't even learn this lesson from 20 years of agony with Swing.
It can be made to look quite well, but yes the defaults are not the best and it requires graphics programming knowledge.
Flutter can do the same. There is not much difference, except that Flutter strives to do the unique part better.
On the Windows desktop your application must be coherent with other applications, since they share a big screen, or rather a workspace.
Either way you want to adhere to the design language of the OS, because it tends to work better than what you can come up with, and also provides familiarity. On Android you don't have to use the prebuilt widgets to adhere to the material design.
Flutter also comes with widgets that look and feel very similar to the Android and iOS ones, so you don't have to reinvent the whole wheel.
We haven't hit release yet, but we're pretty confident we'll have our Android version out on the Play Store within about six weeks.
Thanks, and good luck with the app!
Why not? I write Dart as part of my day job and it's a very nice language. It always does what you expect, gets out of your way. All my mistakes are my own bone-headed mistakes, not due to the language. That's a great trait in a language.
How many devs you know, that also know Dart? Even more so, that they actually have some opinion, not just a knee jerk reaction? Sounds like a huge sampling bias.
>the only things worse than coding in Dart for my friends would be something like "writing amp pages in php using Atom"
As if they've tried Dart AND found it that bad -- both of those are highly unprovable, and put together the unprobableness compounds.
Besides, millions of devs write in PHP and/or use Atom, so if Dart is as unappealing it would do more than alright.
TL;DR; hyperbole.
We all see the knee jerk reactions to Dart. Yet, most people who _actually_ try it tend to like it a lot. We've run actual studies and something like 98% of developers who haven't tried Dart have no strong opinion about it either way. (Which is not better nor worse than Java or TypeScript, which we benchmarked against.) We also run UX studies on Flutter API and tooling, and Dart is not an issue.
Dart is not an easy sell: it doesn't have a gimmick feature, it's just a well-balanced modern language. It was very fashionable to hate it a few years ago. But don't let the vocal minority distort your perception.
Not some support for other languages on a first class basis on the webpage just like Javascript (which direct access to the DOM and everything).
Besides, I'd much rather have the effort go into one new VM (or VM "mode"), so we can solve the problem once and for all. That is, let's have Web Assembly.
Having teams context switch to yet another syntax for basically another language with the same semantics is just not something people are excited to do.. and I think the same group of people google wants to easily appeal to with this language, are the same type of people who DON'T like switching languages often.
I would recommend checking out Unity if you're into making games.
When we started, about 3 years ago now, we looked at many languages (dozens of them) and, objectively, Dart was the best fit for what we wanted to build.
At the time, "we" was a few people from the Chrome team, and me (HTML spec editor at the time). We were all Web people, whose only impression of Dart was somewhat like negative comments in the thread here. When we studied each language, though, we found that impression was really not relevant to Dart as a language for mobile, and in fact it fared better in our comparisons than the other languages we looked at.
I think it would make a lot of sense for people to create other projects very similar to Flutter where Skia is combined not with the Dart VM but with other languages, and for the Flutter framework to be ported -- in a language-idiomatic manner -- to those other languages. I can totally imagine, for instance, a TypeScript-based UI framework like Flutter, or a Kotlin-based UI framework like Flutter, or a Swift-based UI framework like Flutter. After all, in many ways, Flutter is just an evolution of previous UI frameworks like React, DOM/CSS, UIKit, and Android views.
Let a thousand flowers bloom. One day I hope I can write my mobile apps in FreePascal using a reactive framework with a design evolved from Flutter. :-)
Obviously every company will be self-serving in its technology choices. But it seems to me that people got the feeling that Google was doing themselves a favour, more than doing everyone a favour.
Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.
In profiles we see about half the time spent in Dart and half spent in the underlying graphics bindings (it varies wildly per scene, obviously, but as a first approximation this is roughly true). If Dart had been less efficient, then we'd quickly see it in the profiles as a problem. I doubt other languages could have achieved similar results without sacrificing usabilty (e.g. we could get faster performance using C++, probably, but good luck writing a usable reactive framework with manual memory management).
As for the actual content: they really buried the fact that it's based on Dart. Saying that only that it "also works on dart 2" It's almost as if they don't think that's a feature.
Plus, often it's because the iconography is also being developed for the rest of the asset suite, so it's faster/easier to do that with some fancy animation, than it is to do a different format.
I'd love to see more developer-talking heads (and something I want to film more of on the freelance side), but it's more expensive than the happy-mandolin-and-animation approach.
Again, on the actual content, I found that too. It seems as though Google are really trying to hide Dart, I'm not sure what the play is.
1. Implement the lowest common denominator between all your supported platforms so you miss out on key features on each platform; or
2. Bypass native widgets so you end up with your own versions of everything where nothing quite behaves the same as native widgets do (ie Java Swing) and/or you incur a huge performance cost (ie Electron).
This is a touch hyperbolic but only a touch.
But consider this: Android uses garbage collection. iOS uses ref-counting. On a mobile platform, IMHO ref-counting is clearly superior and is a competitive avantage for iOS. GC leads to unpredictable behaviour, unpredictable resource usage and the inevitable stop-the-world GC pauses (at least I haven't seen a GC system yet that doesn't suffer from STW GC pauses to some degree).
On a server, this is less clearcut. The locking for ref counting itself can become hot but this just isn't really the case on an app on a phone.
It boggles my mind that years later (ARC came in in iOS 5), iOS still has this competitive advantage and not only does Android still not have it, nor does the Android-wannabe Fuchsia.
But back to Flutter, it uses Dart. I honestly don't see the point of Dart. Maybe it's just me but I don't want optional typing, or rather optional type hinting. I want static typing. The romance with dynamic typing over the last decade I think is on a downward trajectory with the rise of the likes of Go (really a better Python) and Rust.
Hackernoon's got a recent article covering this exact topic:
FYI Dart2 is no longer optionally typed.
A ton of the community (and in particular teams using Dart at Google) felt the same way and the Dart team has been adapting the language to reflect that. Flutter uses Dart 2, which is statically and strongly typed.
> Garbage collection
GC is a nice value-add to the developer — most of us don’t really want to spend a ton of time thinking about reference cycles etc. but as you note, it has the downside of being a potential source of jank. We mitigate this in Flutter by timing the work we do building frames and scheduling small GCs during idle time. Code here: https://github.com/flutter/engine/blob/8109be8e21604df249b87...
I hope you meant to say "Dart uses GC, Swift uses ref-counting".
> On a mobile platform, IMHO ref-counting is clearly superior and is a competitive avantage for iOS.
Reference counting can also cause pauses since decrementing a single reference can cause a arbitrarily large set of objects to be simultaneously deallocated.
Dart's GC performs memory compaction and allocations are performed by bumping a pointer in the new space. Swift's allocations are much slower since they comb a free-list and it has no facility for compaction.
Well I can already think of three languages that have solved this problem: Erlang, Elixir, ponylang. Every actor has it's own isolated heap with it's own GC. If the actor doesn't allocate then it will never have to stop for garbage collection and even if it does, the pause times are extremely low because the heaps are tiny.
It's surprising to me that modern languages like dart aren't even attempting to pick up this low hanging fruit.
Modern languages are all converging to the same good feature set but don't have anything to differentiate from each other. Kotlin, Groovy, Ceylon, Typescript, Dart? All basically look the same to me, there is no real reason to choose one over the other.
You said "good feature set" rather than "feature set". I'd agree those languages are converging to the same feature set, but the features they're each really good at does differentiate them. Typescript is good for Javascript generation. Kotlin and Eclipse Ceylon are good at generating statically typed JVM bytecodes. Apache Groovy's good for those 20-liners in Gradle for specifying builds on the JVM and Android. Kotlin's good for Android code.
- Is there code linting support in Visual Studio Code? I find that having a style guide, even if loosely enforced, helps a lot in learning how to structure code for long term maintainability.
- The state of packages, in particular those that expose native SDKs, looks just like the early stages of native modules on RN. I know this is a beta, but what is the time frame for when all of these SDKs to mature? Or is this all on the community, in which case, I wouldn't be very convinced to use Flutter considering how long it took for good native modules to stabilize on React Native.
- Why aren't the licensing requirement bits mentioned on the actual doc pages for Drawer and Material Components in Flutter? It's in the FAQ, but if they are required, putting them in the docs would be better: https://flutter.io/faq/#how-can-i-determine-the-licenses-my-...
- Is there a roadmap that is more detailed than the milestones (https://github.com/flutter/flutter/milestones)? With React Native, I know that support isn't going to suddenly dry up because it's an integral part of Facebook's current tech stack. So even if they don't focus on what I prioritize, at least I know it's being improved. With Google and their support reputation, I'm much more concerned about spending time to pick up Flutter & Dart only to have support taper off.
For Visual Studio Code support, the community has produced an extension: https://marketplace.visualstudio.com/items?itemName=Dart-Cod...
Regarding packages, they're a combined effort between the Flutter team and external contributors. There are a bunch in https://github.com/flutter/plugins, for example, with commits from both inside and outside Google.
Thanks for the plugins link. Any idea what Google's stance is on supporting or expanding support of platform plugins? There's no issues for plugins so I can't tell how stable those packages are. So even if it's a combined effort, I feel weary repeating what the early stages of React Native felt like.
Re: plugins, I hadn't noticed until just now that the instructions for the plugins repo say to file issues under the main one. There are plenty there, though. A search for "Firebase," though:
https://github.com/flutter/flutter/issues?utf8=%E2%9C%93&q=f...
turns up ~350 issues.
I can't speak for the team, but solid support for platform APIs is going to go a long way toward adoption, so I can't imagine it's being overlooked.
Kotlin Native is already doing great.
If Flutter was in Kotlin, I'm willing to bet that it's adoption would be 100x of what it is right now. In addition, it gives devs a safe migration path from android to fuchsia.
Where is Kotlin Native doing great?
Right now I wouldn't consider it for anything serious.
EDIT: Regarding Fuchsia, I only mean user space apps. The other layers are a mix of Rust, Go and C++ (C leftovers seem to be being migrated to C++).
I don't believe that's strictly true. Different parts of Fuchsia use different technologies. Flutter is (as far as I remember) the only UI framework for Fuchsia right now, so UI on Fuchsia is written in it (which uses Dart).
If Google plays an Android/Android Things on Fuchsia there won't be much use of C++ for app developers.
If Google plays an Android/Android Things on Fuchsia there won't be much use of C++ for app developers.
Try flutter for yourself to see how this is a major improvement over Java or Kotlin. If Kotlin has hot swapping it would be a good candidate.
I do like Kotlin better than Dart, but Dart and kotlin look alike a lot. And to be honest, most code looks very similar. But development speed in Dart + Flutter is 10x faster than building an app in Kotlin for Android, and Swift in iOS.
- React Native
- Vue.js + Cordova
- Scala + JavaFX
- Kotlin Native
- (whatever I missed here)
?
I am in a mood to learn another language and framework; how would you persuade me to pick this one instead of alternatives?
- The advantages of reactive views, with no JavaScript bridge
- Fast, smooth, and predictable; code compiles AOT to native (ARM) code
- The developer has full control over the widgets and layout
- Comes with beautiful, customizable widgets
- Great developer tools, with amazing hot reload
- More performant, more compatibility, more fun
However, the Flutter advantage might be its performance.
Simple reason is there is a lot of code written in dart that is making money so there is continued support for it.
Naturally there is lots of interesting work that was done.
I am also interested in more native approaches to mobile development, however it does feel a bit like Dart searching for its killer application.
Have fast is Dart 2? I heard here that it enforces static typing, I assume for performance reasons.
Not really sure how to answer that exactly. Fast enough? :-) Performance is one of our top priorities for Flutter (basically priority #2 after "correctness"). There's still plenty of opportunity to optimize, though.
Honestly, so far we haven't found that Dart's intrinsic performance is an issue for Flutter. When we've investigated performance issues in the past, it's usually turned out to be around graphics or bad algorithms in the framework. Our most recent performance issue was related to compiling shaders on the fly; turns out if your shaders are super-optimised to render scenes really quickly, they can end up being so expensive to compile in the first place that you miss a frame or two when you first try to show the scene.
> I heard here that it enforces static typing
Sort of. It's more that the compiler does type inference if you don't specify types (as opposed to just not having any static types). You can still explicitly specify "dynamic" as a type, and generally if you just don't mention types it feels dynamic, still. (The Flutter framework itself always specifies types explicitly, because that helps catch bugs earlier.)
> I assume for performance reasons.
As I understand it, it's partly for correctness reasons -- it makes it much easier to catch bugs -- and partly for performance reasons.
Out of curiosity, have you evaluated Swift as an option? If so, what were the reasons against it?
I find it hard to believe that the people who built Strongtalk, Java's HotSpot, Chrome's V8 and (lastly) Dart, would have trouble finding employment.
What's the story with Flutter in that regard? Is there a nice cross-platform local DB interface that it provides? That would be a killer feature for me, if so.
https://docs.expo.io/versions/latest/sdk/sqlite.html
(expo employee)
edit: I should also say that I'm pretty excited about flutter, think it has a lot of great qualities and hope that it gets some solid adoption. Someone needs to solve these issues with building mobile apps.
Flutter is trying to get modern concepts delivered without towing along antiquated/unneeded technology.
I'd personally be very happy with "compatibility" support of Flutter for the web, which seems to be quite easy (and performant) with wasm+opengl.
PWAs will likely further rise in popularity and be very practical for good cross-platform support and ease of delivery - Flutter won't change that in the short term. In the long term, maybe it will.
There's no coherent view as to what they want mobile to be, just teams pushing their own things.
Dart has PWA support, see https://pub.dartlang.org/packages/pwa
There are plenty of iOS Flutter apps in the App Store. For example, the Hamilton app or. The fact that you can't tell if an app was written in Flutter just by looking at it (or even playing with it) is a Feature.
Literally half of programmers: "Ugh why can't everything be Javascript" Other half of programmers: "Ugh Javascript is the worst language in existence" /s
Given that javascript (esp on mobile) has a hard time reaching native performance, they presumably chose Dart because its design makes it immensely easier to target native iOS and Android without drastically augmenting JS to the point where it's no longer JS.
If there's a non-JS language that's easy to learn for a JS programmer, Dart (and I guess, TS) are it.
For something a bit beefier, we maintain a ‘gallery’ sample app that features a decent selection of widgets and a few demos: https://github.com/flutter/flutter/tree/master/examples/hell...
Disclaimer: I work on Flutter
As for editors, as you note, the instructions focus on IntelliJ/Android Studio, since that’s where the team has put most work, but there’s good support for VS Code (which I believe is what’s in the screenshot). For those who prefer something more minimal, you can find Dart support for vim and emacs too.
Why no plans to support non-mobile? I think it would help increase popularity to have a full solution.
Regarding trusting us to support a new framework, Flutter is entirely open source, so if Google every gives up, the code is still out there and can be maintained. Having said that, since AdWords is starting to use Flutter, it's probably going to be supported for a while.
I believe we have a sample app called "Flutter Gallery" in the app stores. See https://play.google.com/store/apps/details?id=io.flutter.gal...
IOS, Android and any sane application environment have a fully extensible layout and component model to define at compile time.
Say for example on Android I wanted to include a layout but change the text color of all the items in that layout - I can't just do <include text_color="purple">. But I can do pretty much exactly that with React. This is because you can't use variables within layouts like that on Android. Sure, I could build a custom view and add a custom attribute and use that - but this is one of the areas where native isn't as nice as React Native (there are plenty of pain points with RN though).
Maybe I don't understand what you're saying, but it can feel almost like advocating for putting everything in one function. Following the execution through all the functions and methods is a nightmare you might say, but the point is not to follow it through all those layers in the vast majority of cases. The point is to enable a higher level of abstraction that means you don't need to look at those lower levels unless you actually have to change something there.
<HorizontalLayout gravity="top">
<MyCustomSideBar id="menu" height="100%"/>
<VerticalLayout gravity="center">
<Text>Enter a starting date for search</Text>
<MyCustomCalendar id="calendar"/>
</VerticalLayout>
</HorizontalLayout>Declarative, high-level structures (like UI definitions in XML or some other data-only format) really do change the paradigm. You can argue that it's not a useful change, but saying "it's all parsed by imperative logic at some point!" is specious.
In terms of a 'change' as you point out, change is a comparison between two points, and when you compare XML to this declarative paradigm, the main difference isn't along the declarative-or-not axis (because they are similar in that regard), but things like programmability (often with 'templates' in XML) or parseability, in which case in-language DSL-likes work really well (you can write, for example, a lambda returning a UI fragment that closes over some parameters, or you can `.map(...)` a UI fragment over a `List`, ...). The change you may be pointing at is against maybe original GTK-like or Android-Java-like imperative constructs, but this discussion is about a Flutter-XML comparison.
Of course, in the Flutter case, the DSL-like is actually just function calls and doesn't involve macros or a separate code generation step.
You mention following complex nesting chains through code declarations. I understand what you are talking about, but the (awesome) Flutter tooling now has two views that make this far easier: the Widget Inspector, which lets you see and modify the widget tree at runtime (there was a talk on this at DartConf), and the new Outline view (just released a few days ago), which helps you play with the widget declarations in your code.
See https://flutter.io/inspector/ and https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45... (for the outline view)
You can do this in XAML since 2006, and JSP since 2004.
<Button>
<StackPanel>
<Image/>
<TextBlock/>
...
<Button>
<Canvas>
<Ellipse/>
Full disclosure: I work at Microsoft.
Nothing with keyboard-friendly lists, data-grids and trees. And what about "controls"? How come I can't disable the whole form, including tabs and other controls, with just one attribute? Or a panel which can be detached into floating window?
Thats what I would call complex (and useful) widget.
BTW: This is what customers want (checktree, columncombo, dateragepicker, moneyfield with calculator, ...) https://www.tmssoftware.com/site/products.asp?t=vcl
Another place that seems lacking is photo/camera access.
Maps and Camera access are really table stakes for any cross-platform framework at this point. Many app concepts need location/maps and media access.
The architecture of Flutter is superior to that of non-reactive based frameworks like Cocoa and Android widgets.
Try flutter, try the apps, and you will know why.
Note: This is all guess work.
The achilles heel of these projects are always vendor and community support if you want to build anything more than toys. Do they have the endurance to go the distance?
Edit: Hmm, since I am getting downvoted, can someone please say what am I doing wrong here? Thanks. :D
Uses custom rendering engine based on Skia.
Can write UX just once for all platforms if you don't mind fixing the widget set.
Custom widgets work on all supported platforms.
Can in theory be ported to Desktops also, assuming someone writes flutter engine bindings for Win/MacOS/Linux. If this occurs, then you will truly have a modern, cross-XP, write-once-run-anywhere, compile-to-pure-binary, reactive UX framework
Nothing stopping it, nope. I'm surprised there isn't something currently.
That said, it isn't so bad using different render functions for different platforms. The state management and event handling should be 100% consistent.
Besides, going all in on a single render engine limits you to creating special "holes" to utilize controls native to the platform. Im not sure if flutter supports this, but I doubt it.
There is - ironically, by the owners of Xamarin:
https://microsoft.github.io/reactxp/
Hadn't heard of it practically at all since the initial announcement. It seems it's a very small team: https://github.com/Microsoft/reactxp/pulse
- Flutter renders the UI itself rather than using native components, so you get the same experience on both iOS and Android.
- Flutter uses Dart, which can be compiled AOT, rather than relying on an interpreter.
- Flutter is completely open source, tools, engine, all of it. You can go a long way down before hitting iOS platform code, for example, that you don't have source access for.
There others, but those are the biggies for me.
I thought this was an antipattern in modern mobile device Dev, since you're supposed to make your app "look and feel native" by always using native widgets where possible (and was a major argument for why, eg. Cordova was inferior to react native). Has the collective agreement turned on this, or it is simply contentious?
My personal opinion has definitely shifted, maybe partly because I'm tired of inferior Android experiences of the same app, but also because the looks of Android and iOS seem to be converging anyway.
While maybe they couldn't before, many apps seemingly can now get away with one UX for both platforms - that is a strong simplifier and gives a potential branding advantage.
It may be a good idea to still implement some "platform sensitive" widgets (some behaviors are still slightly different), but the demand for them seems to have drastically gone down.
Dart still has a huge hill to climb for mindshare. The staggering amount of community and documentation around react makes it difficult to carve out a competing solution without the same size of community to write documentation, examples, and answer questions on Stack Overflow.
A lot of React Native isn't "Native", but that term is hard to define. They certainly display plaform-own widgets, but afaik they use their own layout functions and such.
It's not JavaScript.
Tons of real world examples: https://github.com/flutter/plugins
I really wish there was a way to pass type information into JS VM so that code could be optimized better.
>Hamilton
https://marketplace.visualstudio.com/items?itemName=Dart-Cod...
(Disclaimer: I'm the author of the Dart Code plugin)
As for yet another framework. Welcome to Google.
Android NDK alone has already been through 6 build systems, 3 public and 3 used at Google.
EDIT: 3 external were ndk-build, gradle experimental, cmake with gradle stable. The 3 internal, looking at AOSP and other projects, ndk-build, blaze and Soong.
https://android.googlesource.com/platform/build/soong/
As for why, I guess reasons.
iOS 10 / Safari / Private mode.