Calling Dart from JavaScript and visa-versa

[dave ford]

Two needs that i haven't heard discussed much:

Need #1. Dart calling JS: I would like to *easily* call javascript
code from my Dart code.

Need #2. JS calling Dart. I would like JavaScript developers to
*easily* consume my Dart code.

IMO, these two capabilities are hugely important to adaption. Even
more so than Dart's published design goal of "familiar and natural".

As far as I can tell, Dart doesn't address either of these needs at
present.

By comparison, GWT does an awesome job at #1 (java calling JS) via
JSNI and overlay types. But they do a horrible job at #2 (JS calling
Java).

The 3 use-cases for this are:

1. I would like to make use of legacy JS libraries and widgets
2. I would like to make use of my own legacy JS
3. I would like to work with others who still prefer to work in
JavaScript

So my questions is this:

1. Do others agree, is this is key to adaption?
2. Are there plans to address this need?

I understand that there are technical hurdles. But I believe this will
be the number one deterrent to adoption.

I saw this thread from October, which states the issue very nicely.
But the concerns were never addressed by Google.

Wish for Dart: low cost of transition from (and back to) Javascript
https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/a1e5a7c09e577bc0

[Chris Buckett]

Seth's blog post from last week gives an idea about using postMessage
http://blog.sethladd.com/2012/03/jsonp-with-dart.html

Probably Not the ultimate solution, but a workable one at present.

hth
Chris.

> Wish for Dart: low cost of transition from (and back to) Javascripthttps://groups.google.com/a/dartlang.org/group/misc/browse_thread/thr...

[Bob Nystrom]

On Thu, Mar 22, 2012 at 8:19 AM, dave ford <*@smart-soft.com> wrote:

IMO, these two capabilities are hugely important to adaption. Even
more so than Dart's published design goal of "familiar and natural".

As far as I can tell, Dart doesn't address either of these needs at
present.

We do understand that JS interop is hugely important for Dart's success, and we're aware that the current support for it right now is pretty, uh, bare bones.

We want to do better here, but we have to balance that against a couple of opposing forces.

1. In a world where your browser has both a native Dart VM and a JS VM (i.e. Dartium and hopefully other browsers that add native Dart support), those two VMs will likely have their own heaps (i.e. memory), their own garbage collectors, and run on their own threads. This means that communicating from one to the other means interacting across threads and memory managers. Doing so either requires asynchrony or synchronizing the GCs.

If we add support for synchronous Dart<->JS interop, we will cut into the freedom that the VM team(s) have in how they design things. For now, we are trying to keep their options as open as possible.

2. When Dart code is compiled to JS, we want to give the compiler as much freedom as possible in the code it generates. In particular, it may mangle names (i.e. rename your identifiers to handle name collisions or deal with differences between JS and Dart) and it will tree shake. Tree shaking means the compiler doesn't generate JS for Dart code that you don't call.

Both of those make it much harder to call into Dart code from JS. Name mangling means you can't assume that just because your function is called "foo" in Dart that it will be called "foo" in JS. Moreso, tree shaking means it may not be in your JS at all if it isn't called from Dart code too.

Any support we add for calling into Dart code from JS cuts into the freedom that the compiler teams have in how they design things. Again, we're trying to keep their options as open as possible, at least for now.

The end result here is that JS interop is a pain now. It will get better over time as we explore the space and get more comfortable nailing down things on the VM and compilers, but we are trying not to rush into that and end up over-constraining ourselves.

Cheers,

- bob

[Justin Fagnani]

On Mon, Mar 26, 2012 at 1:49 PM, Bob Nystrom <rnys...@google.com> wrote:

On Thu, Mar 22, 2012 at 8:19 AM, dave ford <*@smart-soft.com> wrote:

IMO, these two capabilities are hugely important to adaption. Even
more so than Dart's published design goal of "familiar and natural".

As far as I can tell, Dart doesn't address either of these needs at
present.

We do understand that JS interop is hugely important for Dart's success, and we're aware that the current support for it right now is pretty, uh, bare bones.

We want to do better here, but we have to balance that against a couple of opposing forces.

1. In a world where your browser has both a native Dart VM and a JS VM (i.e. Dartium and hopefully other browsers that add native Dart support), those two VMs will likely have their own heaps (i.e. memory), their own garbage collectors, and run on their own threads. This means that communicating from one to the other means interacting across threads and memory managers. Doing so either requires asynchrony or synchronizing the GCs.

Why would it require sync'ing the GCs? I would think that two VMs can have blocking message passing between them without blocking/synchronizing the GCs. Making isolates reentrant seems more complicated, but maybe they already are. I admittedly know very little about VM architecture.

 

If we add support for synchronous Dart<->JS interop, we will cut into the freedom that the VM team(s) have in how they design things. For now, we are trying to keep their options as open as possible.

2. When Dart code is compiled to JS, we want to give the compiler as much freedom as possible in the code it generates. In particular, it may mangle names (i.e. rename your identifiers to handle name collisions or deal with differences between JS and Dart) and it will tree shake. Tree shaking means the compiler doesn't generate JS for Dart code that you don't call.

The way to solve this it to only export symbols when explicitly told to do so, maybe via an annotation. Given that exporting a class/variable/function can lead to large amounts of code being excluded from pruning, it would (hopefully) only be used when necessary, say when implementing a library in Dart for use in Dart and JS, or when incrementally porting an app from JS->Dart.

-Justin

[Josh Gargus]

Blocking message passing is only OK if you don't mind deadlocks (you can easily deadlock both VMs by having Dart call a JavaScript function that calls a Dart function).  If you want the VMs to be able to call into each other synchronously and reentrantly, then synchronizing GCs is necessary.

Cheers,

Josh

[evan]

I'd agree that being able to expose APIs to javascript is important
for adoption.

I'm currently looking into writing a javascript library. The exposed
methods are not that complicated, but the back-end is complicated
enough that I thought I'd look into Dart as an option for better
organizing our code.

However not having a simple, supported, reliable way to expose our API
to javascript is a barrier to adoption for us.

Evan

On Mar 28, 7:41 pm, Justin Fagnani <justinfagn...@google.com> wrote:
> On Mon, Mar 26, 2012 at 1:49 PM, Bob Nystrom <rnyst...@google.com> wrote:

> > freedom that the *compiler* teams have in how *they* design things.

[Bob Nystrom]

On Wed, May 9, 2012 at 2:01 PM, Gerhard Piette <gerhard...@gmail.com> wrote:

1)
I would accept and maybe wish that the interaction between Javascript
and Dart
is based on asynchronous message passing.
I want Dart to be different; otherwise I would still use Javascript.
I want Dart to enable concurrent activity.

We want this too, but we are limited to what the underlying browser and compilation to JS gives us.

 

I want Dart to have the fastest and cleanest implementation possible.
I want Dart to evolve swiftly without W3C or Ecma brakes; at least for
now.

We do have this going for us. We fully intend to standardize the language, but it's really nice to be able to make fast decisions right now.

 

Probably a seamless interaction between Javascript and Dart makes it
impossible to simply plugin the Dart reference implementation in another browser.

Certainly integrating a native Dart VM into another browser is technically challenging, but I think the bigger challenge is political. Browser vendors rightly want to see that Dart is a big win and makes the whole web better before they're interested in doing something like that.

 

Although plugins are no more politically correct anyway.
Unfortunately the high level W3C HTML + JS mix replaces a simpler
lower level API that
would offer true freedom by allowing binaries, including Dart, to be
used as browser plugin.

If you really want native code in the browser, there is Native Client.

 

2)
The biggest showstoppers of Javascript and Dart is the absence of the
distinction
and protection of a public and private API and implementation of my
web application.

Web 2.0 applications are just about presentation, i.e. text, pictures,
colors,...
There is not much reason to copy or protect it except for or against
pishing.

But the Web 3.0, should it ever come, will be an operating system for
complex applications
that nobody wants to get stolen or copied on the client or browser
side.

Games have had this problem pretty much forever. They've tried to deal with it in many ways over the years:

1. Cartridge-based consoles made it hard to physically copy the game.

2. Disc-based consoles still tried to use copy-protection and other technology to make duplication hard.

But fundamentally what works the best is that most modern games take online for granted and don't do anything useful without a connection to a server that the game company controls. Sure, you can have the client code for WoW, but there's only so much that does for you without the WoW servers.

My expectation is that "Web 3.0" apps will be similar. Sure, there will be a lot more interesting client-side code and in theory people could steal that, but it's of limited value without the servers, data, and users on the backend.

For now I see not much reason to prefer Dart to Javascript for
unprotected and hence simple Web 2.0 browser side applications.

I would like Dart to be a great language for small-scale apps too, but our focus is definitely on larger scale.

- bob

[Dave Ford]

Calling Dart from JavaScript and visa-versa  

Any updates on this front since may? 

[Vijay Menon]

Hi Dave,

We've been working on the low-level plumbing for this.  We've added support for synchronous calls between JS and Dart.  You can see some examples in our tests:

Dart to JavaScript:

http://code.google.com/p/dart/source/browse/trunk/dart/tests/html/js_interop_2_test.dart

JavaScript to Dart:

http://code.google.com/p/dart/source/browse/trunk/dart/tests/html/js_interop_3_test.dart

Currently, there are limitations on argument and return types - essentially they must be serializable data.  We're looking at proxying of objects and functions as well.

Cheers,

Vijay

On Sat, Aug 11, 2012 at 8:41 AM, Dave Ford <*@smart-soft.com> wrote:

Calling Dart from JavaScript and visa-versa  

Any updates on this front since may? 

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Ben Ritchie]

Thanks Vijay, 

Look forward to having a play, keep up the good work.. 

From a GWT developer..

On Saturday, 11 August 2012 17:05:09 UTC+1, Vijay Menon wrote:

Hi Dave,

We've been working on the low-level plumbing for this.  We've added support for synchronous calls between JS and Dart.  You can see some examples in our tests:

Dart to JavaScript:

http://code.google.com/p/dart/source/browse/trunk/dart/tests/html/js_interop_2_test.dart 

JavaScript to Dart:

http://code.google.com/p/dart/source/browse/trunk/dart/tests/html/js_interop_3_test.dart 

Currently, there are limitations on argument and return types - essentially they must be serializable data.  We're looking at proxying of objects and functions as well.

Cheers,

Vijay