Calling old javascript code

[André Moraes]

I just read the specification, very fast, but didn't found any parts
related to calling conventions for older javascript code.

Second thing, is possible to split the dart compiled libraries into a
few javascript files and then load them as needed. Similar to what is
made with require.js?

Thanks in advance.

[ProfessorStrelz]

I want to add my vote to a syntax for "calling javascript libraries
from Dart". I'd like to build some examples which do something cool
and compare performance but the sheer uphill climb of redoing an
entire javascript library in Dart is too much. Dart will get a lot
more early adopters if there is a way to incrementally adopt.

[Rémi Forax]

You can use the keyword native for that,
take a look to the code of the library for some examples.

R�mi

On 10/10/2011 04:39 PM, ProfessorStrelz wrote:
> I want to add my vote to a syntax for "calling javascript libraries
> from Dart". I'd like to build some examples which do something cool
> and compare performance but the sheer uphill climb of redoing an
> entire javascript library in Dart is too much. Dart will get a lot
> more early adopters if there is a way to incrementally adopt.
>

[Ben Laurie]

On 10 October 2011 15:46, Rémi Forax <fo...@univ-mlv.fr> wrote:
> You can use the keyword native for that,
> take a look to the code of the library for some examples.

Obviously this will only work with dartc, not the VM.

>
> Rémi

>
>
> On 10/10/2011 04:39 PM, ProfessorStrelz wrote:
>>
>> I want to add my vote to a syntax for "calling javascript libraries
>> from Dart".  I'd like to build some examples which do something cool
>> and compare performance but the sheer uphill climb of redoing an
>> entire javascript library in Dart is too much.  Dart will get a lot
>> more early adopters if there is a way to incrementally adopt.
>>

>> On Oct 10, 7:50 am, André Moraes<andr...@gmail.com>  wrote:

[Toji]

+1 to this! A web library that can't interoperate with Javascript is
like a desktop library that can't use C libs. It will never be as
popular, simply because your forcing people to leave behind a wealth
of well-known, proven code.

[Peter Valdemar Mørch]

On Oct 10, 4:56 pm, Ben Laurie <b...@google.com> wrote:
> Obviously this will only work with dartc, not the VM.

Have I understood this correctly?: Once dart is supported in a VM in
supported browsers (say FF and Webkit/Chrome), it will not be possible
to interact with javascript?

Yikes! That is quite a limitation.

[Florian Bösch]

On Oct 10, 4:56 pm, Ben Laurie <b...@google.com> wrote:

> Obviously this will only work with dartc, not the VM.

There are two cases: 1) Calling from Javascript to Dart 2) Calling
from Dart to Javascript

Not being able to do both is a HUGE issue. People are not going to
abandon all their own JS they have written over the years and all
their frameworks like ExtJS, jQuery, Dojo, Three.js, Glow, Prototype/
Script.acu.lous, Pyjamas, GWT, midori, MochiKit, qooxdoo, Rialto,
Rico, YUI, FUEL, Ally, Ample, DHTMLX, iX, underscore, backbone,
jiglib, box2djs, Processing.js, socket.io, spark, sproutcore,
SoundManager, Sylvester, Zreshk and thousands more.

A relatively simple Dart <-> JS bridge could already alleviate most of
the issues. I think people understand that when they do that, they
will get hurt in performance because calling out to JS. But that is
far more favorable for most then throwing all they knew away.

I personally don't mind the big refactor that much. But a lot of
people do, and Dart could end up like Python 3 or Perl 6.

[Bruce Johnson]

Lars mentioned in the keynote that isolates are a good candidate mechanism for creating a clean boundary between the Dart and JS worlds that could make coarse-grained interop possible. This could work in the same way that it's straightforward to mix services written in different languages so long as it's possible to do efficient RPCs between them.

Seems like a sensible primary strategy to me.