This seems like a clever move by Google to build a "write once, run anywhere" framework so that they can get some amount of apps running on their new mobile OS spike Fuschia. All they need to do is make Flutter compelling enough for Android developers to adopt it.
It’s very clever. Except for Dart. It has an image problem among developpers. I don’t know why but everyone I know seems to hate Dart (the only things worse than coding in Dart for my friends would be something like « writing amp pages in php using Atom »), so unless they can change that or support something like Typescript I’m not sure they’ll attract a lot of developpers.
A while ago Google did try to ship Dart VM into Chrome (think AMP but for programming language). The language is indeed nice, it's a branding and communication issue, as it's often the case with Google.
Well, sorta. The Dart team tried to make it happen, and got a lot of pushback from the Chrome team. I don't think you can claim that Google tried to get it into Chrome.
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.
Well, for one, I prefer React to Angular, so just in terms of how I'd prefer to write my applications JS seems like a better fit. In general I tend to try and stick to things with large and successful communities when I don't have a particularly compelling reason to do otherwise. However, if I were building a mobile app in Flutter, I probably would stick to Dart for any web client stuff that went along with it, just for consistency and possibly code sharing.
>I don’t know why but everyone I know seems to hate Dart
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.
No it's unprovable and completely unscientific, but reactions on this topic seems to prove that it's a widely shared opinion and a fact to consider if Google wants Flutter to succeed.
Disclaimer: I work in the Flutter team, and by extension on the Dart team at Google.
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.
I've tried it on multiple occasions for game making and it was a terrible waste of time, and I kicked myself each time I listened to posts like this thinking I should try it again.
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.
It's probably not a great fit for making games, a lot of the benefits are in quickly generating and updating more standard UIs, not 100% custom drawing like games usually require (although you can do custom drawing of course).
I would recommend checking out Unity if you're into making games.
Dart is indeed a cool language but there was a huge resentment when the Dart VM was about to be shipped with Chrome and create a Google only web. It's a great burden for the language, I hope it could succeed without being put under our throats.
Actually I would have been very glad if other vendors adopted the Dart VM, and we got a new fucking web language to eventually replace (or supplement) JS, instead of the pile of hacks we got.
Dart had a lot of problems, most notably that GC between JS and Dart was never handled well, because the Dart VM and V8 used separate garbage collectors.
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.
We got WASM instead, which I'd argue is much better than support for a specific language, which would lock you in and prevent you from taking advantage of new programming language research.
Why did you choose to support a single language instead of following an approach similar to GTK, with a binding-friendly C API and wrappers around it for major languages (or even just for Dart, the community would have quickly provided the rest)?
Basically because a UI framework's usability is directly related to how idiomatic it feels. So if you write a UI framework in C for C, it will feel nicer than a UI framework in Python for C, or in C for Python. This directly translates into how productive developers can be using the framework, which is one of our top priorities.
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. :-)
Does Google realise that the core of the resistance from the so-called vocal minority isn't about the language itself, but the (perception, at least) that Google was being too self-serving in its promotion and use?
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.
The most attractive thing about flutter (compared to some other crossplat mobile UI frameworks) is the efficient underlying UI framework, so I'm sure if it starts to fail because of Dart they'll be able to eject that coupling and pivot fairly quickly and become more like the competition. However if it succeeds in spite of it's reliance on Dart, then they'll have maybe untarnished its perception a bit.
No, the efficacy of the direct GL canvas native bindings and the view composition architecture are why it's efficient. Yes, there's little runtime language overhead because it's AOT compiled, but that alone wouldn't cause it to win over another AOT compiled mobile device strategy, such as an AOT xamarin project. (And all the other points in that article apply equally to xamarin, for example; and some are just opinion like the xml vs code for layout debate) I'm sorry, but I don't see how any of flutter's real performance wins are truly tied to its' choice of language, and it's a competitive market. I'll be happy if I'm proven wrong in a year or two's time, however.
(Flutter TL here, I wrote large parts of the Flutter framework.)
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).
