How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded? 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.
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?
> How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded?
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.
> How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded? 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.
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).
Hi, I'm on the Dart team too and maintain dart:js which allows you to call JavaScript from Dart. I'm a little busy right this second, but ask any questions and I'll be glad to answer them!
If Google is even half interested in Dart (which is seems to be, since it pays for the Dart team), why doesn't it do any proper moves to push it, besides for the browser which ain't gonna fly by itself?
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.
> Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
> 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.
Pretty much sums up my feeling about the responses too.
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".
What is Google's vision for Dart going forward? Why is it not a primary language for Android?
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)
I actually think microsoft is very much behind non-.net technologies as well nowadays.
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.
disclaimer: I'm a huge fan of TypeScript and the folks working on it, but now work on Dart and JS stuff at Google, so I'm probably biased in all kinds of ways :)
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 ...
TL;DR -- TypeScript is a targeted fix, Dart tries to fix all-the-things. Both approaches have merit.
Dart is a platform play influenced by Javascript with some JS interop, but mostly requires its own new libraries and ecosystem, which allows many things to be fixed.
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)
>Typescript is a layer on top of Javascript and existing Javascript libraries
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)
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.
An interesting advantage compared to Dalvik (or the JVM) is the ability to make use of SIMD. If your bottleneck would benefit from SIMD, you can gain quite a lot.
It does of course require some additional work, but thanks to operator overloading it looks fairly nice.
>Aside from the splash screen, it looks nice and sharp on my retina
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.
Would be neat if they had an adapter for the polymer stuff so that a "material" UI could be rendered in a webpage or with Android's native UI depending on the execution context and no changes to the app code (written in Dart). On the edge of possible, but a lot of work.
> 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.
One of the things that for some reason really confuses me about Dart even though it probably shouldn't is it's status as being full stack.
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?
So in theory it's as easy as using AngularDart and compiling the javascript and throwing that in my rails assets? I feel like I knew that and for some reason it blows my mind.
We use a similar stack except using TypeScript with Angular but keep the Rails backend.
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.
After fighting and fighting with the asset pipeline I finally realized I could just use gulp to build to my public folder and completely avoid fucking with it. It was an amazing moment of clarity for me.
What is your take on swift? Do you think dart can borrow some ideas from swift? Most of it is just syntax sugar, but it is very pleasant to look and work with.
The main thing I miss from Swift is its extensibility letting you extend primitive types like Arrays or Strings, this lets you easily add LINQ-like capabilities even tho Swift doesn't ship with many, see: https://github.com/mythz/swift-linq-examples
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.
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.
Hi! The Dart VM does run on the command line, and can access files, directories, sockets, HTTP, web sockets, and more. The Dart VM is an asynchronous light-weight server. I don't think Dart has a Java EE mentality. Far from it. :)
The SDK is shipped with a standalone version of the VM which can do I/O (via the 'dart:io' package). You can use it to write command line applications and web servers. Basically, it's like Node right off the bat.
I/O performance increased drastically with 1.3. The performance is tracked over here:
The round-9 techempower benchmark shows Dart as very impressive in its "Multiple Queries" runs. However, the json serialization not so much. Is there something in the works to speed this up or technical reasons it does not shine here?
Also, what are the plans for speeding up regular expresssions?
With Dart 1.5 announced, I am interested in ensuring that Round 10 includes 1.5. I just posted a question [1] to our most active Dart test contributor: does the >= 1.3.0 specified in the pubspec.yaml ensure that we'll be testing on 1.5 in Round 10 or should we be more explicit about 1.5.0? If anyone else knows the answer I'd appreciate the feedback.
It will just cause a `pub get` fail (Package foo requires SDK version >=1.5.0 but the current SDK is x.x.x), but it won't prevent the application from running. Only `pub` cares about that pubspec.yaml file.
The two are mostly decoupled. The core language hasn't changed much since 1.0, and I think TC 52 is mostly focused on nailing down stuff that either shipped before 1.5 or won't appear until after.
I don't know many details here, though. The committee is still pretty new and the communication channels are still being set up.
> One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
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.
Up until recently due to some issues with build scripts and MSVC parameters our bots building 64-bit SDK on Windows were just silently building 32-binaries. I have fixed[1] it couple of weeks ago, but my fix did not make it into 1.5. Sadly it's not just a build script fix, but also some changes in Dart VM to accommodate for ABI differences, so we decided not to merge. Next release will have 64-bit dart binary on Windows. Bleeding edge SDKs already contain correct version of dart binary.
I recall hearing someone at the office mention that, but I don't know the details. File a bug or ask on the mailing list and someone who knows better than me can sort it out.
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.
re: GWT. GWT is still actively developed and making progress. I just talked with some GWT team members at I/O, and they're adding better JS-interop (like we are), incremental compilation, and are looking at web components support. One thing we talked about that would be nice is GWT-Dart interop, (if we get everything else done).
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.
Although it won't fix all the language boilerplate problems, we are also adding Java 8 support to GWT shortly, which does let you go from this nastiness :)
button.addEventListener("click", new EventListener() {
public void onEvent(Event e) { Window.alert("Hello"); }
});
to this:
button.addEventListener("click", e -> Window.alert("hello"));
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?