Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.
In my line of work (web analytics), I have to use third-party JavaScript libraries in order to integrate tools onto my page, like Adobe Analytics (formerly Omniture SiteCatalyst) or IBM CoreMetrics or WebTrends. Fully instrumenting a page generally involves wiring up other JavaScript on the page with event handlers for web analytics functions (e.g. video play/pause/progress, with video name & length as parameters).
Most analytics tools are also moving towards asychronously-loaded script-injection techniques, like Adobe DTM or Ensighten. These usually include the ability to selectively load relevant libraries, like only having video tracking on video pages.
What's Dart's story for interacting with tools like that?
I'm not the best person to ask about JS interop, but I know it's something that other people on the team put a lot of effort into.
> I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
dart2js likes to have access to all of the Dart code while it's compiling, so it can do global optimization, but as far as I know, that doesn't affect JS interop. Talking to JS is all dynamically dispatched at runtime, so the compiler doesn't really care about it.
(We can also do deferred loading of Dart code now too, though I don't know the details.)
> What's Dart's story for interacting with tools like that?
Beyond the general JS interop story, I don't know if we've done anything specific there. I believe you should be able to talk to JS code even if it's loaded much later.
Great question. Generally dart:js will let you do interop: https://www.dartlang.org/articles/js-dart-interop/. It's designed to interact pretty well with the dart2js compiler. However it feels a lot like you're using a foreign function interface. For example, calling a the global method Object.keys is: js.context['Object'].callMethod('keys', [obj]);
For Custom Elements (one of the new web components specs) we did something better: you can register the Dart wrapper type associated with that element. Then whenever you get one of those elements, it automatically looks like the Dart type. We used this heavily in the new core_elements and paper_elements packages. Here's an example of defining a type like that: https://github.com/dart-lang/core-elements/blob/master/lib/c...
Ultimately we'd like to make something similar for all JavaScript objects and expose it from dart:js. That would make interop almost seamless (especially if we could generate the types from DefinitelyTyped's APIs).
1) Properly package and add "batteries" for a server side version of Dart. Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
2) Make a Google version of node.js using Dart instead of v8.
3) Even better, merge (1) and (2) for a serve side framework with both good syncrhonous (e.g Django like) and async (e.g Node like) story.
4) Support Dart as a first tier development language for Android.
1) Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
2) When people say "node.js", they usually mean at least two different things. Forgive me if I'm assuming too much, but I'll try to answer. Node.js is "javascript + v8 + server", and the equivalent for Dart is "dart + dart vm + server". So we've delivered that. Sometimes, when people say "node.js", they mean "express + v8", and Dart has "shelf + dart vm". You can check out the shelf package here: https://pub.dartlang.org/packages/shelf
3) There are a few emerging server-side frameworks out there (I mentioned shelf above). Dart VM is asynchronous, so you'll get a Node-esque experience. There aren't plans to make a fully sync server API.
4) That would be cool!
> Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
These aren't the same things and likely a major difference between a popular language and a non-popular language.
It's mostly "we provide the basics, let it to the not-really-that-big community to come up with the stuff you ask for" or "there's already some 10 ho-hum independent efforts for that", instead of: "we (Google), ourselves, will create, guide and provide top tier implementations for those things, like we do with Angular for example".
I really like Dart. Google is pretty much the only company trying to break the tyranny of JS in browsers.
(e.g. Microsoft clearly said that they are betting on C# and .NET as their main offering for everything - would be nice if Google was capable of this sort of direct messages)
My experience with their TypeScript initiative has been really smooth, feels like they're trying to improve JS instead of inventing something new (by sticking as close as possible to the ES.next specs). The generated JS is very close to the original, both in size as readability.
The way I like to think of it:
If the main thing you want in JavaScript is types and classes, TypeScript is brilliant. It adds exactly those things, and does so in a very attractive and seamless way. Classes are already in EcmaScript 6, and I wouldn't be surprised if TypeScript annotations make it into a future version ES (there's a strawman proposal: http://wiki.ecmascript.org/doku.php?id=strawman:types), so the forward compatibility story is good too.
If you want to fix more things in JS, such as:
* massively improve all core libraries and types
* improve the DOM
* add integers
* add operator overloading including [] []=
* make Map a distinct type, instead of all objects being maps
* switch from prototypes to classes
* removed undefined
* fix == operator
* remove implicit conversions
* tree shaking: no worries about which library is less KB's
* add named arguments
* add many features ES could add but at a faster velocity
* consistent libraries (e.g. Dart standardized on Futures)
* ... probably more stuff I'm forgetting ...
Typescript is a layer on top of Javascript and existing Javascript libraries that adds hybrid/latent typing. Typescript doesn't require a new ecosystem, but instead allows enhancements to the existing one.
Both approaches are valid.
(Disclaimer: MS employee, but had this discussion with Gilad a few weeks back)
With all horrible issues JS has: unpredictable perf, library hell.
Also my issues with TS are:
1) what if future ECMA will bring incompatible changes with current TS ? TS will break compatibility or we will have another EEE from MS ? Dart clean break seems like a safer approach.
2) there is no cross-platform IDE for TS (yea I know plugins - but Dart has stock cross-platform IDE)
3) TS perf will be always as good as JS
Any links for the perf issues you mentioned? There's some massive JS apps at Walmart and PayPal.
Dart on Android?
Will the Dart IDE look correctly on Windows 8 high-dpi devices? (I know that's partially an Eclipse problem)
In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working on it! Having two language virtual machines with objects that can contain references to each other is quite technically challenging. There's a bunch of work to be done to address that[1]. Along the way, we're working with the larger Chrome team to address any other requirements they have.
> Dart on Android?
The Dart VM does run on Android right now [2]. My understanding is that the performance is impressive relative to Dalvik/ART, though don't quote me on that.
[1]: https://groups.google.com/a/chromium.org/forum/#!topic/blink... [2]: https://code.google.com/p/dart/wiki/Android
> Will the Dart IDE look correctly on Windows 8 high-dpi devices?
Aside from the splash screen, it looks nice and sharp on my retina Mac.
> In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working to make it a comprehensive web language, both client and server-side.
It does of course require some additional work, but thanks to operator overloading it looks fairly nice.
Heh, I believe it, but it is a bit of a mess on high-dpi Windows 8 machines (e.g. Lenovo Yoga 2 pro). Some elements get scaled, some don't, and the entire thing looks broken. It is functional, just ugly.
[1] More than https://code.google.com/p/dart/wiki/Android
You could either build it as a mobile web app, or if you need more of Android's APIs there's https://cordova.apache.org/.
> We are working out a proposal that is somewhat similar to async-await in C#. Again, we hope to finalize that in time for the next rev of the standard. Details as soon as coherent articles explaining it all can be put together.
I really want to use AngularDart for the front end of an application I am using and I would like to use Rails for the back end as well as some static content. I can't seem to find an easy way to make that happen. In addition, how does Dart interact with existing JavaScript libraries?
IMO integration is as straight-forward as it gets, basically just use a HTTP Client to call JSON services. Here's an AngularDart example for calling a REST backend: http://japhr.blogspot.com/2013/10/http-requests-in-angularda...
I've also created a JsonClient that provides a terse API for calling JSON services: https://github.com/dartist/json_client
Essentially your Angular code should boil down to one JS file, one CSS file and be hosted in an index.html. If you're dealing with modern browsers a bit of fiddling with the cross domain policy and the withCredentials flag will allow you to host the static assets anywhere (not the same domain as the Rails box).
Otherwise the easiest thing to do is compile into the /public folder of Rails. I wouldn't host in assets as you'll likely be using gulp / grunt so the compilation phase that Rails assets hosting provides will be done for you already.
Dart comes with a rich functional and Stream API's on collections so most of the time you wont need to extend it (same LINQ examples in Dart: https://github.com/dartist/101LinqSamples), but unfortunately you can't extend built-in (or external) types which means you need to use top-level methods which can break-up the flow of your beautiful expression flows. Extensions is also important for minimizing unnecessary abstraction and maximizing re-usability since you can extend without being forced to create foreign wrapper API's.
IMO Extensions are one of the most important traits for keeping a minimal friction-free language, something I see Go and Swift benefiting a lot from.
Dart does have powerful mixins (https://www.dartlang.org/articles/mixins/) but you can only mixin into classes you define (i.e. not built-in or external types).
But otherwise I find Dart's optional-typing a tonne more productive than Swift's strict type inference / generic enforcement, Dart also has a rich consistent library, integrated package manager, static analyzer and overall better development experience.
Although there's little overlap as Swift is mainly for creating iOS/OSX desktop apps and Dart is focused on rich Web Apps. Basically the only times when you'd be able to choose one or the other is in command-line scripts, I'd still prefer to use Dart for.
I'd like to Dart to happen. What worries my is that Dart has Java EE mentality. Hipster programmers won't touch it and lack of traction may kill the project. What's the solution? Performance may be a great USP. Rewrite Gmail in Dart, so tools like Streak, Rapportive and other extensions won't kill the performance.
We aren't planning it, we've already done it. Dart comes with a command-line VM with a full-featured (IO, networking, etc.) set of libraries[1].
The performance is quite good and getting better[2], from what I understand.
[1]: https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... [2]: https://www.dartlang.org/performance/io/
[disclaimer: I work on the Dart team.]
Redstone is becoming increasingly popular: http://luizmineo.github.io/redstone.dart/
Whilst I've built a simple Express-like API: https://github.com/dartist/express
Which also includes a complete port of node's popular jade view engine: https://github.com/dartist/jaded
I/O performance increased drastically with 1.3. The performance is tracked over here:
https://www.dartlang.org/performance/io/
1.4 added experimental support for ServerSocket references, which allow you to share a socket across isolates (~"workers"):
https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
[1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/864
I don't know many details here, though. The committee is still pretty new and the communication channels are still being set up.
1. One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
2. Will we see another UI rendering layer other than DOM for Dart?
Because Dart compiles to JavaScript, we're limited in some ways in what we can do here. We do, of course, support Web Workers, but those have a bunch of constraints that make them difficult to use in practice.
We have tried to make single-threaded async programming more pleasant. In particular, Dart comes with built-in, very rich Future and Stream types. Even better, those are deeply integrated into the code libraries, including the DOM.
Every asynchronous DOM operation in Dart returns a future, which is much more pleasant to deal with than raw callbacks. Likewise, things like events are exposed as streams, so you can map and transform them like any other stream of data.
I gave a talk on Dart at Strange Loop last year[1] that talks a bit about this. Skip to around 38 minutes.
> 2. Will we see another UI rendering layer other than DOM for Dart?
Good question! There are a few different frameworks that people have built for Dart that expose their own ways of expressing UI. I think they all ultimately fall back to the DOM because that's the primitive the browser gives you, but what you as a programmer deal with may be fairly removed from that.
These days, I mostly do command-line Dart stuff, so I don't have a good lay of the land here.
If I'm using GWT, should I be thinking about using Dart instead?
Yes. We on the team, of course, use Dart heavily. My day job is working on pub, the package manager for Dart, and a slew of other libraries, all written in Dart. Our API[1] doc site is written in Dart.
Likewise, we have an increasing number of internal customers who give us the kind of feedback you only get from someone who isn't obligated to see your project succeed. :)
Obviously, a bunch of customers we can't talk about, but I can say that Google Elections and Google Fiber use Dart. Google has an internal sales tool also written using Dart and Angular.dart.
I'm biased, being on the Dart team, but I think Dart is a much nicer language that Java, so I would choose Dart for a new project. GWT might still be a good choice though if you have a large existing investment in Java that you can repurpose in the client. Many enterprises have hundreds of thousands or millions of lines of Java code that aren't going anywhere anytime soon.
So, should you think about Dart? I guess that depends on how ready or willing you are to migrate your code away form Java. If you were thinking about rewriting in JavaScript, then I'd definitely say consider Dart. If you're happy with Java and GWT, then you can keep going that direction.
button.addEventListener("click", new EventListener() {
public void onEvent(Event e) { Window.alert("Hello"); }
to this:
button.addEventListener("click", e -> Window.alert("hello"));
The code-labs provide pretty good, practical walk-thru's: http://io2014codelabs.appspot.com/static/codelabs/dart-start...
Thank you.
I don't know the details, but I believe sanitize uses of innerHTML to avoid some common security vulnerabilities. More details here: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...