Hacker News new | past | comments | ask | show | jobs | submit login
Announcing Flutter beta 1: Build beautiful native apps (googleblog.com)
373 points by nicpottier on Feb 27, 2018 | hide | past | web | favorite | 338 comments



The responses to this article are pretty discouraging to be honest. Cross platform mobile development is a pain in the ass. React Native is a step in the right direction but, as anyone that has actually used it knows, it still has some very rough edges.

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.


I can't speak for everyone, but my problem with flutter isn't the framework - it's the language. Or, more accurately, the fact that it's not a JVM-based language.

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).


Flutter will be based on Dart 2 when it finally ships (I believe). Dart 2 requires strong-mode (aka: types are inferred/required, and will fail static analysis if you do unsafe things)[1]. You can read more about strong-mode here[2].

[1] https://www.dartlang.org/dart-2#strong-mode-and-static-typin...

[2] https://www.dartlang.org/guides/language/sound-faq


So I understand this correctly, Dart just pivoted language styles 7 years after being in stable?

So all old Dart code won't work now? This seems much worse than the Python 2 - Python 3 jump.


> Dart just pivoted language styles 7 years after being in stable?

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.


Type inference goes a long way to mitigate this. And most old code tended to use type annotations even though they were optional.


Flutter has a concept called "plugins" that specifically is intended to let you use existing platform libraries. That's how we implement things like notifications. Dart code talks to the OEM side that is implemented using the native library. See https://flutter.io/platform-channels/


Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern. The other thing to consider is that this advantage of code reuse was never realized to iOS. Writing apps for iOS & Android always meant having a C/C++ core with platform-specific shims; J2Objc more recently let you write it in Java but again that just lets you write the core in Java with 2 platform-specific independent frontend implementations. A lot of developers just wound up writing the app twice & shifting as much logic server-side as possible (which hurts battery too). This is the first time you can write the app once & run on both iOS & Android. AFAIK Dart is also only a requirement for the front-end. You are still free to use whatever language you want for your business logic. I'm not 100% clear yet on how good the bridging story is but I suspect it's not bad.


You could also use a C++ core with Qt/QML to target not only iOS and Android but also Windows, macOS and Linux, all from the same codebase.


Wow, let me stick the hot pokers in my eyes first! Qt/QML in a mobile app is something only a masochist could love.


It depends if you're trying to make your UI consistent with other apps on the platform, or consistent across platforms.


>Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern.

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.


Disclaimer: I work on Flutter

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.


I think its also to get people to look away from the JVM based things and prepare developers for its upcoming Fuchsia platform.


And it adds to the already high level of churn in the UI development arena. Dart is a perfectly fine language but is it noticeably better than Kotlin? To use Flutter I have to learn a new framework, a new language, and rewrite pretty much all my app infrastructure that currently runs on the JVM.


To be fair, you can learn the majority of Dart in a a day or two if you're familiar with JS and Java. It's essentially the best parts of both.


>and rewrite pretty much all my app infrastructure

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.


Lack of libraries is a valid reason for preferring another language.

But, when Go came out, there were no libraries. And it didn't get so much bad press.


>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.


You know... you can call almost any language from any other as long as both have some kind of FFI?

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.


Is Swift that much different? Genuinely asking because it seems like a similar situation to what you described.


> Oh. And many remember Dart being optional-typed (like Typescript).

So? Some could argue it's a very productive approach.


Even the Dart team themselves stopped arguing it's a productive approach. Dart is going all strongly typed, after seven years of feet dragging.

Dynamically typed languages are a thing of the past.


it would be nice if dart had a more expressive type system, why do we say types are the future, then gimpy the language with basically a java type system to which most static type people will say is not the good definition of a static typed language?


The Java type system is pretty solid, and the languages that followed (C#, Kotlin, Swift) improved only marginally over what Java had already done in that area.

I think it's a great middle ground between no type system and what Haskell and ML offer.


the java type system is unsound :D it's not very expressive... i mean i don't expect haskell level but i think we can do better than current java, especially for new languages


Unsound is what you want.

Sound type systems are pretty much unusable.


>So? Some could argue it's a very productive approach.

Some could. And others look at it and think "Python" or "JS" speed app. Oh. And harder to refactor/detect errors.


Well if it would be React Flutter Native, HN would be happy. Thats the recurring theme here, add react to foo for instant upvotes.


> 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).


> Dunning-Kruger is real.

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!


Yes, it absolutely can be, which is pretty amusing. Since I've gotten downvotes, apparently people think I may be one of those cases. But hey, at least I'm only arrogantly dismissing people's arrogant dismissal of Flutter ;)


Seeing the age of this comment when I came to the thread and it being at the top I kinda brushed it off and scrolled on to the rest of the comments.

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!


The reaction here makes me look very positively on Dartlang. At least it hasn't got the fanboy "sun shines out of my new programming language" problem.


The irony is that Dart was co-created by Lars Bak, who is also known for creating Chrome's V8 engine.


Indeed if anyone ever earned the right to make a new language - they did. They were the first to make js really fast and they pulled every trick in the book (from their extensive VM writing experience). But they were ultimately blocked by things like the ability of js objects to change shape. I sympathise with their frustration and from an engineering point of view they did the right thing. They solved the root cause of the problem which was the language.


As somebody who has no dog in the game, I hope this takes off. Javascript and the world of frameworks frankly looks horrible from an outsider's perspective.


> js objects to change shape

Could you please share more details?



What languages suffer that problem? Elixir? Rust? Juice?


Putting together this list made me realise how much is not just language, but language + framework / language + architectural pattern.

* 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.


Functional programming is fun, but ML family of languages, especially Haskell, can be very complex if you're not a CS/Maths type. My favourite languages as of now are Emacs Lisp and Ruby (I'm new to Ruby, I like it because it's got a rich ecosystem of libraries and nice, expressive and extensible syntax/paradigms in a clean package; tho I'd probably reach for Django if I had to write a web app, definitely not Rails), and although Haskell is incredibly interesting to play with, writing an actual, complete program with it is practically impossible for me, even if it's small. Just too many things to learn. There definitely is a lot of hype around them, but just for the most part.


Is most of the hype the result of developer “signaling”?


That's my take. Some e.g. Ruby/Rails was due to ppl in other languages (Java?) suddenly seeing how 'easy' web development could be. Many of the others... yeah.


I'm still on that Clojure(Script) hype train TBD. A few years later and I feel like I'm almost where I want to be in terms of productivity.

Prepare for the ReasonML hype train though - which I am also on! :P


Have you tried Weex or NativeScript? They are simpler than React Native, leveraging Vue.js.


I came here to ask the question: Do I need to use Dart? And it looks like the answer is yes. That means Flutter is not a GUI toolkit as advertise "Flutter is Google's new mobile UI framework". Nope, Flutter is the gui component of a new language. As mobile devices get bigger - big phones, tablets, pixel thingies or whatever - it'd be nice to port existing software to them. But that means we need a GUI toolkit, not a new language.

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.


It's hard to make a GUI toolkit that doesn't cater to a specific language. All languages have paradigms that they follow, and toolkits that are language agnostic just end up feeling out-of-place on all languages rather than all but one.


There is nothing that prevents Fuchsia from running other languages.

AFAIK, they already support Rust.


You just need to look one or two pages in to see why DART, and therefore Flutter is a waste of time.

Here is how we make an HTTP request in react-native:

  fetch('https://facebook.github.io/react-native/movies.json');
And here is how we do it in Flutter:

  import 'dart:io';

  var url = 'https://httpbin.org/ip';
  var httpClient = new HttpClient();

  await httpClient.getUrl(Uri.parse(url));

Why does the HTTP package need to be imported? Every single mobile app worth its salt makes HTTP requests, I shouldn't have to think about importing it, this is just more yak-shaving. And parsing a url to an URI? Fuck off fake-Java, just let me tell you the damn location of my resource, I don't care about the leaky abstraction of URIs.

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 problem with your argument is that "every single mobile app worth its salt" will want to handle slow networks by showing pretty progress indicators, and just calling a single method won't do that.

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.


> showing pretty progress indicators, and just calling a single method won't do that.

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!"


In case you don't know, Hixie used to be the editor of the HTML specification, so I'm pretty sure he's familiar with what that HTML and CSS are like and isn't likely to inadvertently recreate the web.


If I'm not mistaken, a large proportion of the Flutter team is made up of people who were part of the early Chrome team, many of them having worked on the web for 15+ years.


I am glad that I did not know that, it might have influenced my decision to post and reply with my opinion (an apparently naive one).


Well hopefully I won't make the same mistakes this time. :-)


Not every mobile app needs to perform HTTP requests; many games don't, for example. JavaScript is a language for web development, so it makes sense that HTTP requests come "for free"; Dart is a general purpose language and so importing this for programs that don't need isn't a great idea.


Your counter argument doesn't make sense in the context of Flutter; it's not a tool you would use for mobile game development.

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.


So type import whatever. It's really, really not that hard.


That flutter code could have been done in 2 perfectly good lines, if you weren't being deliberately misleading, and one is an import that isn't exactly going to cost you cognitive load.

Your JS code isn't better at all. They're just as easy as eachother.


You're forgetting the polyfill for fetch. Not every browser ships with it out of the box.

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.


I recently rewrote a small app in flutter that was originally react native. Initially I was sceptical, mainly about learning dart. But it wasn't hard to pick up.

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

[2] https://pub.dartlang.org/packages/flutter_redux

[3] https://github.com/flutter/flutter/issues/1150


This is exactly one of the things I was curious to know about Flutter vs alternatives. Having already been burned by Dart 1 and its promise of web components, I'm more cautious for a cure-all.

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.


How is the integration of Flutter apps with the rest of the Android system/apps? Given that Flutter does not use the platform native widgets -- do Flutter apps look or behave different?

How difficult it is to use a Java library from Dart?


Disclaimer: I work on the Dart VM and Flutter engine

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.


Given flutter can call down to iOS with plugins, and given that the apps are native, apparently, is it not possible to natively use the actual iOS widgets instead of reimplementing them?


For widgets it's not just calling to iOS that matters, but being able to render the widgets as part of the painting process, which Fluter does as a completely separate process from how iOS renders. So to integrate it, you'd need something involving compositing native views properly and yet propagating touch events to them, or rendering native views on top but doing the right masking, or ...


AOT compiled to native code that uses the native instruction set - no interpreter/vm involved.

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)


"Can write UX just once for all platforms if you don't mind fixing the widget set."

Whenever something promises this, it usually only works kinda well on it's "home" or "main" platform, and runs crappy everywhere else.


Your statement isn't true of Qt or Java SWT or Java AWT. They don't have a main platform.


And I'd argue they don't run well on any platform...

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.


Agreed. QT is by a very extreme margin the most competent I've seen. On an absolute scale, I'd still classify it as mostly incompetent. I still agree with the Mono team - your model and view model should be xplat, while your view should use platform-specific APIs.

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.


Unlike QT, SWT, or AWT, Flutter doesn't bind native widgets, but renders everything itself, so the way it works is more comparable to Swing though...


Swing is the perfect example that such approach simply doesn't work.

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.


Most interesting apps tend to use custom Android views, layouts and behaviors to create a unique, but consistent look and feel.

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.


When I first got started with Java at a time when Javalobby was my Hacker News, there were endless rants and debates about Swing and native widgets. Yet, 20 years later Electron seems to have won the cross-platform platform and no one seems to care about native widgets - only memory usage!


Swing is the perfect example of devs that don't bother to read documentation and just go with defaults.

It can be made to look quite well, but yes the defaults are not the best and it requires graphics programming knowledge.


Qt is exactly the same, it does not use native widgets bit reimplements them (and leverages the system APIs to get correct colors, icons, and sizes). but everyone seems to be hell-bent on reinventing qt every three years so ... :p


And when used like that, they don't work that well, at least not Java. However, I would say that Java does have a home platform in Android, and the Android toolkit.


Exactly this, its a better technical design for UI systems. And it works cross platform. And it has native compilation. And it has hot code reload. This is big.


> Can in theory be ported to Desktops also,

https://github.com/google/flutter-desktop-embedding


If Flutter is ported to Desktops, would that be a good alternative to Electron-based app development?


Xamarin already does this. IMO the best choice currently if you need to go multi platform.


Disclaimer: I work on Flutter

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...


[flagged]


Which is a contentless statement.

Besides, if it was JS, it would be tied to a crappy language, and also not have several of the advantages above (plus lower speed).


Why do people hate Dart?


Dart was conceived as better than Javascript, but it ended up drawing the short straw in the browser. It ended up with shit on its face, so to say. So people identify Dart with that expression.

But nothing could be further from the truth. It is a modern productivity language, like Kotlin. Anyone will be productive in a matter of a few days.

With such a low barrier, why then carry on the legacy of Javascript with its weird edge cases? So I think Google made the right call.


>why then carry on the legacy of Javascript with its weird edge cases?

but many languages could have done that, instead google chose the route to create another not much has improved here language, other than..they made it


What's wrong with using multiple languages?


Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support. It didn't catch on, and one of the reasons is that this is right around the time when CoffeeScript started to fall out of favor, JavaScript got a lot of new features that alleviated enough of the pain points that people didn't want to deal with debugging code that was compiled into JavaScript, and stuff like Emscripten and TypeScript moved into the space. So it feels like the state of JavaScript has moved on by where Dart was, it still have enough JavaScript influence that the JavaScript haters don't really want to touch it, it's not enough like JavaScript for JavaScript enthusiasts to really like it, and there's no community around it so if you want to work in it and Google hasn't provided a library or framework that does what you want you need to roll your own.


> Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support.

Actually (and this is ultimately the reason for a lot of the political resistance), Dart was imagined as a replacement for JS, with an in-browser Dart VM as the ultimate preferred target for front end. Dart2JS was overtly a bridge until other browser vendors signed on by adopting the DartVM or implementing their own. (It was used even for Chrome, because Google wanted to avoid Chrome-only or “runs better in Chrome” Dart code on the public web, but that was insufficient to quell political resistance.)


Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53" https://www.dartlang.org/guides/language/language-tour#numbe...

Or a completely lack of parallelism, which is an omission that grows ever larger as even mobile SoCs are flirting with double-digit CPU cores.

So you got all the downsides of JS with none of the community/libraries of JS and with performance promises that only manifested with a custom build of Chrome. That's not a happy place to end up.

If they hard-kill dart2js then maybe Dart could turn into a nice language, but dart2js is what keeps Dart from becoming interesting. But since it looks like Dart 2 is going to still support the web via dart2js it doesn't look like Dart's going to get any more compelling.


> Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53"

As your own reference notes, Dart ints are defined as arbitrary precision, but dart2js uses js numbers (IEEE 754 doubles), so it's outside the listed range are problematic with code thst might be deployed via dart2js; it has no issues on Dart VM.

> Or a completely lack of parallelism

Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.


> As your own reference notes, Dart ints are defined as arbitrary precision, but dart2js uses js numbers (IEEE 754 doubles), so it's outside the listed range are problematic with code thst might be deployed via dart2js; it has no issues on Dart VM.

Yes, but it's now a quirk of Dart which is the problem. The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.

> Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.

It's the same as JS+WebWorkers which is enough to claim a checkmark in the parallelism feature box without actually supporting anyone's use case (although JS+WebWorkers almost had shared memory which would have helped a little until meltdown/spectre happened). Since all communication goes through an extremely expensive pipe and all objects are serialized & copied it doesn't even work well in a shared-nothing context, which really needs to be able to move things to work well. That barely lets you do basic thread offloading in narrow circumstances when data passing needs are very small, to say nothing of using parallelism to speed something up.


> The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.

What would you do instead? Any choice other than the underlying platform's native number type will significantly negatively impact performance and make interop much harder.

It doesn't matter how much nicer your preferred number type is, if you make "a + b" or "getNumberFromPlatform()" slow, your users aren't going to be happy.

Scala.js uses JS numbers for Byte, Int, Float, and Double (though it implements correct overflow for operations on fixed-size number types).

Kotlin.js does the same.

TypeScript uses JS numbers and has no integer type at all.

Elm says ints are 32 bits, but uses JS numbers to represent them.


You do what all those examples you just listed do, you say int is 32-bit which fits in JavaScript number just fine.

Then for longs you either don't support them or suck it up and pay the manual cost, which is what kotlin.js does.

Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.


> you say int is 32-bit which fits in JavaScript number just fine.

32 bits isn't actually enough for many uses today. Lists with more than 2^32 elements are not unheard of. File offsets larger than that are certainly a thing.

Dart only has a single integer type, so restricting it to 32 bits would restrict all users of integers to that size.

> Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.

isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)


> Lists with more than 2^32 elements are not unheard of.

In the use cases Dart targets yes, yes they are. They are extremely unheard of.

BUT even if they aren't, you can't use those from dart2js anyway. JS arrays are limited to uint32 lengths:

"Every Array object has a length property whose value is always a nonnegative integer less than 2^32"

https://www.ecma-international.org/ecma-262/5.1/#sec-15.4

Now sure you could make your own list type that lets you index to 2^53 in Dart, but you're into custom list territory now and math operations on a 64-bit long being a bit slower than native is unlikely to be relevant. You're probably not using flat indexing at that point anyway.

File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64s, as node.js discovered when trying to use JS Number for inodes ( https://github.com/nodejs/node/issues/12115 ) So things that actually need large numbers don't work anyway.


> In the use cases Dart targets yes, yes they are. They are extremely unheard of.

Dart is a general purpose language it wasn't intended to be web front-end only.

> File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64

Dart ints aren't limited to 2^53 except when using dart2js. It's an arbitrary size type, otherwise. Anyplace it would need to deal with inodes, the dart2js limit wouldn't be a problem.


> isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)

Because it allows more general code to apply isNaN to nums generally, and always be false for ints (or potential future subtypes that likewise can't be NaN), even leaving aside JavaScript environment questions.


But dart supports static typing, so that's just awkward. What does it even mean to take a num? What do you do with a generic num that may or may not be a double where isNaN makes sense? What value does this even have in a world of only int & double anyway? If a function returns 'num' does that mean isNaN is now something I need to worry about, or is it just badly over-generic code and it meant 'int'?

Stepping back, though, methods like isNaN only apply to a specialized subset of numbers, not the base on which all numbers build off of. So putting it on the base number class is the wrong layering. Same reason that bitwise operators are on int instead of num, because they don't apply to all numbers.


dart2js is a very small sliver of what Dart is.


The original Dart announcement was a presentation entitled "Dart: A Structured Web Programming Language." Dart has evolved beyond that mostly by necessity; people weren't adopting it for web programming, and so if it was going to survive, it needed to adapt.

http://gotocon.com/dl/goto-aarhus-2011/slides/GiladBracha_an...


Right, but that legacy isn't a great reason to hate on what Dart is now


Programming languages have killer apps that define how people engage with them. Perl was "instead of using shell scripts with sed/awk you can use a 'real' programming language." Java was "here's C without so many footguns." C# was "here's Java without having to deal with Sun/Oracle." Dart was supposed to have a killer app around web development and didn't make it. Even something like Flutter has incremental improvements over stuff like React Native, Xamarin Forms and other cross-platform UI toolkits. There's still no killer app there.


I don't hate Dart. I hate Google's presumption that their new client GUI platform will be so irresistible that it will convince me to use an unloved no-community language that's not usable in any other context.

And... why? There better be agood reason not to pick Kotlin, or C#, or Swift, or Go even? There better be something very special about Dart but... there isn't, so far as I can see. So it seems like Google is foisting this on us arbitrarily, or from internal political calculations. Which just taints the whole thing.


> not usable in any other context

I'm using Dart for the web and on server side. Really loving the language.

> seems like Google is foisting this on us arbitrarily

It's been in the works for at least 2 years now.

> There better be something special about Dart

A good article on why Dart's a good fit for Flutter: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

> no-community language

I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow.


> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow.

I'm on the Dart team, and I agree.

We have been pretty internally-focused the past year or two. As someone who cares a lot about open source, that makes me kind of sad. But, also, the reality is we had pretty good internal adoption and not great external adoption.

If we're going to get to a million happy users someday, we need to first have thousands of really happy users — we need to fit our product really well to a customer base and then grow from there.

If you look around, you'll notice that almost all successful open source projects start with a pretty solid base — often developed entirely privately inside an organization — before they grow to a larger ecosystem.

Our internal users have been a great set of users to focus on for a while. They give us great feedback, have very large projects to work on, and, well, they pay the bills.

I also think almost everything they deal with is relevant to external users too. (Except for some minor stuff around build systems and versioning where Google's monorepo system is quite different from the outside world.) I believe by working to make our internal users really happy, we've focused Dart into a product that will ultimately be much better for external users too. If you were to see the stuff they complained about and that we fixed, odds are you'd be right on board with them.

Years ago, I felt like Dart was trying to be all things to all people with not enough coherent focus. The past couple of years (and some org changes) have helped improve that, I believe.

Once Dart 2.0 is out the door, my hope is that we'll get back to working like a normal visible open source project. But we need to have a solid foundation we can build on before that makes sense. Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"


I hear what you're saying, and it's true to some extent with projects, like say, opencv.

> Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"

However, kotlin, rust and go all offer counter points to your argument with regard to languages.

That simply isn't the case; the community is full of people who have things to say about this... if you're prepared to listen.

...this just sounds like an excuse to avoid engaging with the community, and a flip off to the very smart people out there who have meaningful things to say about this stuff.

> The past couple of years (and some org changes) have helped improve that, I believe.

Well, if it has, you have some serious work to do to communicate that to community, because it doesn't feel like it to me.

This kind of comment from the Dart team (aka. community has nothing to offer us) is extremely irritating, and just makes me, personally, not want to even bother to try what you've built.


> However, kotlin, rust and go all offer counter points to your argument with regard to languages.

I don't think that's true.

Kotlin was pretty well baked when first publicly launched. Most of the syntax, semantics, non-nullable types, etc. was all there on day one. There have been lots of changes since then, of course, but Kotlin is still roughly the same language it was before. It's not like it's turned into a Lisp or something.

Rust has made more significant changes since they launched, but most of the foundational questions have the same answers that they did on day one: maximize safety and performance and be willing to accept complexity and strict compile errors to get it.

> This kind of comment from the Dart team (aka. community has nothing to offer us)

I'm sorry, but I think that's a very uncharitable reading of what I wrote.


> I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow.

From another hand you have language driven by needs of mature and complex products/company/engineers, and not by random people who decided to use dart today for some hobby project or soon-to-die startup, and then will switch to another hotness next month.


Flutter is just an open source project. You are certainly welcome to use it (and maybe even contribute to it), but it isn't in any way something that Google wants to force anyone to use. We hope people like it and want to use it, that's all.


Uh, really? So then you either have no plans to try to make Fuchsia OS a major commercial success? Or, do you plan to offer multiple first-class-citizen ways to write native apps on Fuschia, not just Flutter/Dart? Because if the idea is to make Fuschia the next Android and Flutter the official native app platform, then sorry but your comment is a little wilfully naive.


Fuchsia doesn't require using Flutter. Flutter is just one possible UI framework you can use with Fuchsia.


What are others? Will there be first class Kotlin support?


If someone implements one. :-)


I don't get it either.

I recall using it a few years back to build a simple in-browser OSM widget on top of Leaflet. It was a fairly enjoyable experience. I remember that once my code compiled without errors, the widget just worked.

The only explanation I have is that it's just a "normal" language and doesn't really have a strong differentiating point unlike Rust, Elixir, etc.


Let's see. People hate Go, because it doesn't have generics and is missing dependency management.

So, people hate Dart, because it has support for generics and comes with a package manager?


What? One of the reasons I love Go is it doesn't have generics, and I say that after 7 years spent in Java. People don't like to be forced to think differently because they're lazy and can't motivate themself to change the way they think and program.

Go is different, Rust is different, people throw shit on Go because it's not Java or C# or Python, because it doesn't do what they would like it to do, not because it doesn't have generics. Sure, occasionally generics would be useful, but it's not a reason to hate a language.


I was trying to say that one shouldn't expect a sober, reasonable discussion about pro / cons of any programming language here. (As every discussion of anything Go has amply shown)


Golang looks nice, but my problem with it is that it seems to have nothing even resembling python's sqlalchemy. As I understand lack of generics is the reason for that?


Different people hate different things.

And I don't think that anyone hates Dart because it has generics.


Dart is a perfectly fine opensource programming language with a familiar syntax. Is it perfect? No, but it's good enough.

There is nothing about Dart itself that would remotely justify the shit it gets heaped upon here.


They could've made a C API, with a thin Dart wrapper around it, allowing multiple languages to create their own bindings, like GTK did. Instead, they decided to couple a UI framework with a language that almost no one is using. Maybe because it was easier for them to implement it that way, or as an attempt to make Dart popular after developers have been snobbing it for years.

In the end, if flutter becomes the de-facto standard for mobile apps, developers will hate it for the same reason developers hate on javascript: it's not necessarily for its technical merits, although they do play a role, but because it's forced on you with no other choice.



Can C talk directly to iOS and Android?


It would be very unpleasant, but you could write a pure C iOS application which uses the standard platform GUI libraries.


I like Dart. They've just finished pushing out Dartlang 2.0. I'm hopeful that they'll be able to refocus now, especially on things like JavaScript interop, which really must be fleshed out to make Dart practical for general use.

I am personally disappointed that they've reoriented to focus specifically on client-side development, but if it gives the language and ecosystem the attention and revitalization it needs, it'll be worth it.


> They've just finished pushing out Dartlang 2.0

Note that Dart 2 is only available in pre-release builds. Work is on-going.


My sore-point is the lack of community and enthusiasm for it. The available resources and libraries are limited.


I tried to contribute to a couple of official Dart web projects.

It was extremely poorly handled by the Angular Dart team and I learned the hard way that the “source code open to public” != “open source, contributions welcome”.

I really wanted to use Dart over the JS ecosystem (it’s similar to TypeScript syntactically but with a package manager that’s not npm and none of the JS implementation baggage!) but the project is very clearly catering to internal customers at google with 0 care for any sort of community.

I should emphasize that all my contributions were fixes and not some sort of feature requests - the latter would be straight up impossible to discuss I am sure.

Good luck to both the Dart VM and Flutter team - solid engineering from what I can see, just a pity that community management was shit and put me off unless I get paid to work with them.


I do wonder why Google doesn't take a more open, community approach to Dart. I mean, what do they have to lose?

As a Googler said earlier, they've built the fundamentals quasi-privately already, do it seems they can only win by making it a community project.

Is it any less community driven than Swift though?


You’re right they have the infrastructure almost all in place. I wish they did care about the community especially when communities like Go really are thriving.

I do not have any experiences with how the Swift project is run, hoping someone else sees this and comments!


Well, having it as the language for Flutter will obviously only help in both regards.


https://flutter.io/platform-channels/ is intended to make it easy to integrate with many existing "native" (OEM-side) third-party libraries.

There's also a surprisingly large number of pure Dart packages. See pub.dartlang.org.


Set of C# libraries is nothing compared to number of libraries in Java or Python, is that a reason to hate C#?

Look at this from different perspective, you have a chance to start one of the future most popular library in Dart.


It IS a factor.

Many people choose Python because of the libraries available.

Many developers just want to ride the wave, not innovate.


there's nothing innovative about rolling auth flow yet again.


C# has everything that an average project needs. With Dart you'd need to reinvent the wheel several times for something common as medium-size mobile game.


I need good support for OpenCV and other image/color manipulation libraries. Two years ago C# totally sucked on this so I went with Java. Has it changed?


Nope.

However, it is easy to expose C methods (not entire opencv interface) to your app via PInvoke.

I do this often, and allows me to quickly pop in any native library how I want.


Is that reason enough to hate Dart ?


No, not the language itself. But community involvement is important.


Having a scripting layer is ok-ish, but then you can't use your native lang (swift, .net/xamarin, java, etc).

So this mean that to have "cross-platform UIs" you MUST commit to a inferior language glue. Js is bad, Dart is better, but Swift/C#/F# is WAY better.


Just a note: one of Flutter's differentiators is that renders every pixel, straight to OpenGL / Vulkan. It doesn't do cross-platform the way RN or Xamarin does it. It's more like Unity.

Since most featured mobile apps nowadays have very custom UIs, we hypothesize that this is a very important feature going forward.


This part I could agree, and for most of my apps make a lot of sense.

I download the code and run the sample where is possible to integrate flutter with the "host" language. Is better than react native, but I wish it have a more ergonomic api.


Most featured mobile apps are still using the native widgets. They're just styling them.


Dart compiles to machine code plus the rendering is mostly impl’d in Dart so you can change basic things about the rendering in Dart, FWIW. In general the dichotomy you’re painting b/w scripting and native languages can hold, but the details make the difference. One interesting thing in this case is having a single language that AOTs but also JITs. The hard thing is re: interfacing to platform APIs, which the OS usually provides in its blessed lang (Java / Obj-C).



I really want to give my thanks to the Flutter team. Flutter allowed us to finally (and fairly quickly!) build a music production application on Android with feature parity to our iPhone offering. We're just three devs working on this in our spare time and I think without something like Flutter we'd never have been able to complete this.

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.

https://tizemusic.com/


@bbreier this looks very interesting! Can you talk a bit more about how your overall _dev_ experience was, working on Flutter? How many times did you have to go _native_, where you had to create platform channels for features Flutter didn't already expose? How much code sharing, if any, were you able to achieve? Were there any corner cases you ran into?

Thanks, and good luck with the app!


Also very interested to hear the answer to this question


It looks like there's custom UI going on there, how did you all find that on Flutter?


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.


Why do people hate Dart? It looks like a nice language, has a well thought-out design. (I just looked at tutorials, havent written Dart code)


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.


Perhaps because it's just another boring Java-clone language controlled by a large corporation, with no redeeming features?


I'd never use Dart otherwise, but just to get a decent cross platform development toolkit I'd do it in a heartbeat.


> I'd never use Dart otherwise

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.

TL;DR; hyperbole.


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.


At the moment (and for the next 5 years I think) WASM is just a way to write code you'd write in C/C++.

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).


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 people willing to widely share their opinions aren't always the same people whose opinions matter when it comes to actually making decisions.


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.


Dart is a major reason that the efficient underlying UI framework works so well: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf


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).


I hope so. Flutter is intriguing and is clearly in its own league as a toolkit.


It's not for Android developers. It's for cross platform developers so it just had to be nicer than that.


Sorry to do the picky thing and criticise a completely unrelated feature, but I wonder if we have, or are about to, reach peak "happy mandolin and animation" marketing videos. That is starting to feel old to me, early 2010s.

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.


Seems old, but it actually tends to convey the point more succinctly than a real-worlder.

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.


I'll take mandolin anyday. What we are hearing here is ukelele. Awful, horrendous ukelele.


I keep hoping but year after year these videos are still here.


What alternative for a friendly intro would you suggest?


I wouldn’t... I think people must like them?


So this is the problem with any cross-platform GUI toolkit: you have to make one of two choices:

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.


> Maybe it's just me but I don't want optional typing, or rather optional type hinting. I want static typing.

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...


Interesting approach. I'd read some articles about the inner workings.


That 100ms hard-coded value is interesting. What about 120fps devices?


Ah, ic, this is only allowed during idle time and nothing is getting painted.


> 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.

FYI Dart2 is no longer optionally typed.


Dart2 is optionally typed in that you don't have to enter the types. It's different from original Dart in that previously, if you didn't enter the type Dart would assume you meant "dynamic", whereas Dart2 will infer the type based on what you are actually doing. The net result is that the compiler/analyzer will catch more bugs but the code looks more or less the same.


> But back to Flutter, it uses Dart. I honestly don't see the point of Dart.

Hackernoon's got a recent article covering this exact topic:

https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf


> Android uses garbage collection. iOS uses ref-counting.

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.


> (at least I haven't seen a GC system yet that doesn't suffer from STW GC pauses to some degree).

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.


> Modern languages are all converging to the same good feature set but don't have anything to differentiate from each 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.


"iOS has reference counting"


So I took a good look at the docs and as a React Native developer, I do have some questions:

- 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.


I can answer a few of these.

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.


The extension I saw in the docs, but I didn't see code linting as one of the features. Is there code linting included?

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.


Linting is included with the extension (I think it's way down in the list of features on its page, but it're there). The flutter command line tool (included with the SDK) comes with a formatter, so it'd be insane not to hook into it.

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.


Mobile development is hard to get in. Maybe it's that I'm an outsider, but yet, on the second most popular platform it costs you an Apple computer and $100 for the IDE (IIRC), and on the other one the development experience is godawful (tools are slooow and janky, hard to integrate with your usual tooling, the program structure is incredibly complex, lots of XML, and then there's Java). Having looked around a bit, it seems to me that it should be easier to start with Flutter, the filesystem layout, the project configuration, the language, they seem managable, and I've seen some youtube videos where a guy only used VS Code and the Flutter command line. If I can just get going with Emacs and the Flutter's command line tool, that'd be awesome. Mobile app or game development seems to be a nice way to earn some money developing software solo, just from your laptop. And not having to deal with JavaScript is a nice way to spend more time for oneself. So definitely going to re-try this (tried it before but my impression was that I needed Android Studio, and that's a show stopper).


As a backend developer I find flutter great. Recently created an app that uses Go compiled with gomobile as a backend for flutter UI. Widgets are great, Dart lang is easy to learn and understand :)


I really wish that this was in Kotlin - a truly beautiful language which only won because of the community and not because of a large commercial enterprise.

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.


Fuchsia is developed in Dart.

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++).


> Fuchsia is developed in Dart.

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).


I mean the userspace apps.

If Google plays an Android/Android Things on Fuchsia there won't be much use of C++ for app developers.


We are using kotlin heavily in a large software company where Java/Clojure is common. Great language, get to use the JVM. What's not to love?


Considering I've always avoided the JVM like the plague...


Low level stuffs in Fuchsia is in C++. The rendering engine skia used by Flutter is in C++.


I mean the userspace apps.

If Google plays an Android/Android Things on Fuchsia there won't be much use of C++ for app developers.


Eh? The two languages are both pretty neat, and pretty obscure. I can't take your 100x idea seriously.


While Kotlin is a nice language, it doesnt come with a "hot code swap" feature. The goal of flutter was to making mobile development fun and fast again. Dart comes with the hot swapping feature. Changes to your code are shown in the app immediately. This is a big win!

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.


The Flutter project is considerably older than Kotlin Native.


Why should I use this instead of:

- 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?



Can you provide a summary of the convincing arguments from that article, in 1 or two sentences? I plan to read it myself, but I think the parent comment is relevant.


From the article:

- 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


You missed Xamarin, which seems to be popular enough to have its API documentation prominently ranked in search engine results, suggesting there seems to be .NET programmers doing mobile development.


I would add NativeScript and Weex to the list.

However, the Flutter advantage might be its performance.


This feels like the Tennessee Valley Authority but for Dart. Just send people out there digging ditches in Dart to keep Dart's makers employed.


Flutter originally used JavaScript, we ended up switching to Dart after studying dozens of languages. Our choice of Dart very much did not come from wanting to support Dart, in fact, originally, I think the Dart team was a bit confused about what we were doing. :-) You can see this a bit in how, for example, we started with out own style guide and only over time have slowly converged it to match Dart's style guide (it still isn't 100% merged).


Good job. Js is cancer. As a Swift developer I would never use it, but Dart actually looks nice.

Have fast is Dart 2? I heard here that it enforces static typing, I assume for performance reasons.


> How fast is Dart 2?

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.


>after studying dozens of languages

Out of curiosity, have you evaluated Swift as an option? If so, what were the reasons against it?


Yeah, Swift was on our list of languages we considered. At the time, Swift wasn't open source and it wasn't clear what Apple's plans for the language were, so we didn't do a deep dive on its technology. It's possible that if we were to start over today that we would consider Swift more seriously.


>to keep Dart's makers employed

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.


It feels a bit like that.

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.


I laughed. Dart's low adoption but continued support by Google is programming's biggest mystery.


Disclaimer: I work for Google and write dart for my current project.

Simple reason is there is a lot of code written in dart that is making money so there is continued support for it.


It's also a clear counterexample to the idea that Google always abandons projects.


its coming don't worry


Actually Dart's low adoption is an even bigger mystery in itself.


how is it a mystery? it seems quite clear the a language made to appeal to people who don't like taking risks in their programming languages would not want to learn yet another syntax for another language with the same semantics... What I find a mystery is how google doesn't get that


My biggest hangup with a little project I wrote in React Native was using device storage. I didn't want my app to interact with APIs (which RN seems good at), and just wanted a little local DB. The whole `create-reactive-native-app` flow was pretty good up until I needed to have a local DB at which point I'd need to eject it and use various libraries in each of the ecosystems (or realm, I think).

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.


Looks like it has sqlite support - https://pub.dartlang.org/packages/sqflite


I'm not sure when you last tried it, but CRNA apps (insofar as they run in the expo client) have sqlite support these days:

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.


How does Flutter fit in with PWAs? From a high level they both seem to do the same thing: cross-platform mobile application platforms.


PWAs are far from being cross-platform mobile apps, Flutter (or React Native) is much better for that.

Dart has PWA support, see https://pub.dartlang.org/packages/pwa


I'd imagine it's mostly a performance thing. It also seems like Google is aiming to use this to help get more apps on Fuchsia as well. It may end up becoming the preferred method of making new apps on Android.


That would seem to indicate that--at least from Google's view--PWAs are a dead-end solution. I guess I can stop going through the PWA tutorials.


To me it indicates that they still differentiate between web and native - which I find reasonable, at least in performance terms.

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.


I don't think Google has a view: go to Google I/O, you'll find in one room the Chrome team harking at how PWAs are the future of mobile apps, and in the next room the Android team harking at how their new features solidify their advantage.

There's no coherent view as to what they want mobile to be, just teams pushing their own things.


Well, unless the performance characteristics of PWAs are going to be much different than that of Electron apps, I would stick to native personally.


I see Flutter the same as in React Native and Xamarin, cross platform mobile UI framework that provides native feel. PWA is an attempt to make web apps/sites work as well as native, web app/site by default is "cross platform". Google is not going to replace PWA with Flutter or vice versa. Just two groups within Google with different ideas on PWA vs native dev. Similar to GMail vs Inbox, Polymer vs Angular Elements, Go vs Dart, Allo vs Hangouts etc.


Was wondering the same thing. Seems like a stop-gap solution for now until PWAs really hit their stride in a couple of years. PWAs are still missing a few features on some of the platforms, but hey Safari just now finally announced Service Worker support.


While PWAs make decent use of the lowest common denominator (browser), it comes at a gigantic complexity cost impacting both development ease and performance.

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.


The performance difference for one thing - this comes not only from not using javascript, but also from the fact that there is no DOM to update and has been designed from the beginning to maximize use of the GPU.


Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: