It's true that Dart is an optionally-typed system, and that type annotations are ignored at runtime. That may seem scary at first, but we built an analyzer that statically analyzes your program and gives you feedback (errors, warnings, and hints).
Dart is used at Google to build very big and complex apps, and our engineers use the analyzer in their build/CI systems to check their program. The analyzer is also wired into their IDEs. So they get feedback if a method doesn't exist, or you are trying to pass a variable into a method that is expecting something else.
The Dart team is also working on an optional analyzer feature called "strong mode", which does even more static checking. In strong mode, you can't write code that is incorrectly typed (but, you can still write code that is dynamically typed, if you want to).
Our experience, at least internally, is that as your program matures and grows in complexity, developers appreciate the extra checks provided by strong mode. The win is that it's something you can turn on later, when you're ready. Early on in the program's development, you are probably refactoring a lot and you don't want to bother with strong mode. This scalability is a win for us.
The developers on this project are using Atom https://github.com/atom/atom/ for their day to day Dart development. They are contributing to the Dart plugin https://github.com/dart-atom/dartlang, and implementing a Flutter specific plugin https://github.com/flutter/atom-flutter-dev. The Dart SDK https://github.com/dart-lang/sdk provides the basic source code analysis tools. All of these projects are open source, on github, and see regular commits.
I don't want another language in my build ecosystem. Between javascript (necessary for web), objective-C, Java, C++ for shared stuff, adding another one that provides no genuinely useful semantics or performance implications is a sheer non-starter.
Indeed. One of _the_ biggest selling points of React Native is the promise of near-instant over-the-air updates for iOS and Android.
Are you familiar with Codename One (https://www.codenameone.com/ )?
It seems to me that what we implemented there is roughly in the same direction although not as mature.
Could you potentially generate smaller js libraries if the language was statically typed?
The decision to use Dart for this project seems to me like an attempt to find a lifeline for it. That's fair enough, but it could ultimately be a highly limiting factor and the reason it doesn't go anywhere. That would be a shame as cross-platform frameworks need to keep evolving to be more useable and performant.
React Native in my eyes has done a fantastic job of demonstrating highly performant JS driven applications that are accessible to tons of developers. An added bonus is the luxury of bundling in millions of existing NPM modules along with existing native modules. Facebook in my eyes is doing better at solving the code portability problem than Google, they are extremely focused, whereas Google, they want us to build things in a million different ways. Which direction do we go? Web components? Angular + Typescript? Dart + Flutter? Or maybe some new development far on the horizon that is the new way?
lmao what universe do you live in
If all the browsers supported a real programming language in their runtime, JS would die like Flash is doing.
What problem is this trying to solve?
The big draw of React-native is that I can reuse largely the same core code everywhere, and for the parts I can't (mobile UI), I'm at least working in a language that everyone on my team is familiar with, with the same pattern as elsewhere (react/flux).
This to me sits in a weird middle ground between RoboVM/Xamarin and Cordova, but has the benefits of neither (it uses a language that I'm not already familiar with, and doesn't give me access to native controls).
Am I being unfair? (Is there a killer feature here I'm not seeing, beyond being backed by Google?)
It doesn't pack a huge VM/class library like RoboVM/Xamarin and doesn't try to gap two VMs/GC like Xamarin on Android - instead it uses IPC for talking to system services using it's custom service definition language to define the IPC API/schema in cross language way.
Dynamic language/custom VM lets them do a better job at development experience (dynamic code reloading) as opposed to buggy/complex one you get from trying to statically compile bytecode or bridging two VMs to share objects.
IPC architecture then lets you write performance parts in portable native code (eg. C/C++/Rust) or system specific language (eg. Java/Swift/Objective-C) and it should be easier to make cross platform - hiding the dirty FFI crap.
Dart is much closer to C# than you think, go look at some examples - it's quite a productive language from my experience with it so far.
Custom GUI framework means it doesn't behave/look the same as native framework (just like webview tech) but at the same time it can also mean higher performance (certainly better than WebView), consistent behavior between platforms and versions (faster development), etc.
Overall I like it, I can see a GUI framework on same tech built for desktop (custom widgets but same rendering principles) and doing client side development in Dart sounds great - fast prototyping and iteration because of it's dynamic nature but the optional type system gives you same guarantees as C#/Java type systems.
I couldn't find a whole lot of independent benchmarks but I'd suspect that at least in Chrome, it does outperform V8.
I guess I'm just not the target developer for this, though. If I want optional static types I can implement typescript incrementally into my existing stack, while retaining the code portability benefits. For desktop apps, NW.js is aiming to plug that gap, and I wouldn't have to give up my npm modules.
Another poster mentioned waiting until it sees a push at Google I/O before taking it seriously. I'd settle for them just to explain the problem case that drove it's development.
EDIT: I hadn't spotted harryf's reply below that makes the point about transparency better than I have above, kudos.
A minimal "Hello World" RoboVM app adds 3mb per CPU slice. I'd assume packaging the Dart VM has a similar footprint.
The problem on GWT is that it builds too slow on bigger Apps, while ScalaJS builds even faster. Also the compiler needs to be reworked on lot's of side, I'm not sure if 2.6, 2.7 will handle all these problems.
But I don't think that GWT gets a 3.0. But thats mostly caused by the fact that this is a really really old technology and there are newer technologies which google builds upon. (AngularJS). They replaced lots of GWT Things already (Cloud Console, Google Apps Console, App Engine Console).
Still no proper support for mobile platforms. You basically have to write most of the bindings yourself. Specially a pain in Android, given JNI.
Only QML widgets get some platform theme support, not the C++ ones, so you need to add the QML engine to the set of libraries to pack.
Also you are supposed to code all native UI behaviours yourself, thus having more work than an hybrid development of native mobile OS language (views) + portable C++ libraries (business logic).
If you pack Qt libraries with your application it is around 30 MB for the runtime dependencies. You can also scare the user by asking them to download the libraries as separate app instead.
I got my demo application using Java + C++ and C++/CX + C++ around 5 MB.
Finally if you look at the set of exposed platform APIs across all mobile OSes, they are way behind Xamarin and their commercial licenses are much more expensive.
This is I idea I as an outsider get from the talks at Qt events and the various iterations of QML and WebViews that took place in the 5.x releases.
most people hear Qt and immediately think about heavy desktop applications. its a shame really, Qt is pretty awesome atm for mobile development.
but i agree, for many people C++ is a no-no, even though Qt C++ is pretty straightforward with all the helpers they provide (like the parent-child memory management).
Maybe that sounds appealing to some, but for me is just choosing between two evils. Unsafe dynamic language on one side - kitchen-sink low-level language on the other side.
I personally would like something in between, but still cross platform. F# with Xamarin looks most appealing to me, but Xamarin is unfortunately not free, so...
From what I could understand in the Qt 5.5 release notes, this has hardly changed.
The point is that Flutter application code is intended to be 100% Dart. Just like React Native application code is 100% JavaScript (and React Native itself isn't).
What you mean is there: https://github.com/flutter/flutter (99.1% Dart)
Honestly, between the use of a relatively exotic language of dubious quality with types that are "optional and unsound" (https://www.dartlang.org/articles/why-dart-types/), their custom widget implementation that who knows how well is going to work, and lack of web support, it doesn't seem very attractive.
React-native seems a much safer bet.