Creating a JS Library with Dart

[David Mouton]

Hi,
I'm creating a JS Lib, called MyLib.js, but coded with dart.

MyLib have a single function doSomething() that i can called from another script like MyLib.doSomething();

How to do this in Dart ?

Dart2JS does not include unused function !

Is there a way to force it ?

[Bluenuance]

I do not know if this works, but maybe there is some attribute in the reflection library to mark classes?, methods? as "do not remove"

[Thomas Down]

The Dart/JS interop stuff doesn't allow JS to call Dart functions unless a callback wrapper has first been created from the Dart side.

So your Dart "library" will need a main() function which does something like:

           js.context.doSomething = new js.Callback.main(dartDoSomething);

...which will hopefully be enough to let dart2js know that the dartDoSomething function -- and any code it depends on -- needs to be included in the JS translation.

               Thomas

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

[Alexandre Ardhuin]

See http://stackoverflow.com/questions/15669163/expose-dart-functions-to-javascript/15669488#15669488

2013/5/2 Thomas Down <thomas...@gmail.com>

[David Mouton]

Thanks.

JS-Interop is quite interresting but quite heavy too.

look at this example :

import 'package:js/js.dart' as js;

void main(){
  String foo() {
    return "bar";
  }
 
  js.context.foo = new js.Callback.many(foo);
}

My generated JS weighs about 470Kb !

And it does'nt works in a web workers :(

I've got an error when i post a message.

2013/5/2 Alexandre Ardhuin <alexandr...@gmail.com>

[Dan Grove]

+v...@google.com

[Don Olmstead]

I honestly wish there was a dart2jsThatsUsableInAnotherJSProgram compiler. As is dart2js does way too much mangling to be of use.

https://gist.github.com/darthapo/3916195 shows a comparison of cross compilation output. The TypeScript stuff looks totally usable by some arbitrary JavaScript application while the Dart stuff has such a large compilation it can't even be displayed in the gist.

I personally could get away with writing Dart at work if there was dart2js output that looked like the TypeScript output. For my home stuff I don't really care, but it would be nice to never have to touch JavaScript ;)

[David Mouton]

Completly agree.

Personally, after trying typescript, I chose to develop all my JS/HTML5 projects with Haxe.
This really is an amazing language, strong, modern, experienced, with many features like abstracts, generics, type inference, etc...

2013/5/2 Don Olmstead <don.j.o...@gmail.com>

[Mike Watson]

For cross-browser/mobile HTML5 JavaScript developers, Dart has to play well with the existing JavaScript code base, but I don't see any emphasis on that. I'm not even sure what Dart is trying to be.

[Bob Nystrom]

On Thu, May 2, 2013 at 11:32 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

https://gist.github.com/darthapo/3916195 shows a comparison of cross compilation output. The TypeScript stuff looks totally usable by some arbitrary JavaScript application while the Dart stuff has such a large compilation it can't even be displayed in the gist.

TypeScript has a much easier job here. It doesn't define its own types or runtime library.

We definitely need to do better with the JS output from Dart (and the dart2js folks are continually improving it), but Dart isn't just a syntactic sugar over JS like TypeScript and CoffeeScript, it's a distinct language with its own built-in types, methods, and semantics.

This isn't to say there's anything wrong with the approach TypeScript and CoffeeScript take here. Certainly staying much closer to JS's semantics makes interop and compilation much easier. Dart is just trying a different angle. We get a lot out of being able to define our own runtime library and semantics, but it does certainly make interfacing with the JavaScript world harder.

Cheers,

- bob

[Don Olmstead]

Yep I totally understand that it wouldn't be an easy feat. I just mentioned it because it would be a great gateway drug to the Dart world, and I could easily sell it at work if there were a dart2usableJS compiler. To me this is a more important story than the js-interop.

[Xavier Mehaut]

Hi bob

I follow dart from its inception, and developped with both typescript and dart. With the time, sirry to say that, i prefer definetely typescript to dart fir its flexibility and its capability to merge with the js world. it is also less complex to handle.

Best regards

Xavier

Envoyé de mon iPhone

[Mike Watson]

I just got word that a contract requires IE7 support, so obviously Dart2js is not going to work, but I'm still going to advocate for using on mobile because I like the language. I could use in more places if it supported IE8, which still has 20 to 25% of the browser market. I don't quite understand why Dart2js output is so obscure that it can't be patched with shims like other libraries can in the simple cases. The size of js-interop is an issue. Dart2js doesn't work well in the JavaScript tool/lib eco-system.

I watched one of Gilad Bracha's talk about Dart again yesterday http://news.dartlang.org/2012/11/gilad-brachas-dart-talk-from.html and he stresses the two prong approach, with Dart2js being the second major prong, which makes me wonder why there is not more work being done on it, for example, bringing js-interop into the SDK and throwing more resources at it.

"NetFlix has given up on Silverlight" http://www.infoq.com/news/2013/04/Netflix-Silverlight-HTML5 makes me wonder if the Dart VM has any future on the client. Google has given mixed messages about this.

"Netflix is responsible for one third of all downloaded traffic in North America... If there were any doubts before, now we can say with a high degree of confidence that Silverlight has no future. With Flash suffering from similar problems, it remains for HTML5 to occupy the RIA space in the following years."

It seems TypeScript and by implication ECMAScript 6 (since they track one another) is going to take this market, and that's unfortunate because I like working with Dart better than the alternatives.

[Jim Trainor]

<two-cents> 

I'm writing quite of bit of Dart code at the moment. The project's goals totally resonate with me and more than justify any pain that may be experienced integrating with legacy Javascript code (I consider pretty much all Javascript to be legacy code!).  And, yes, I do have to call dart from Javscript myself - at least in the short term. As long as there is some way to call into the dart code from Javascript, even it requires some hoop jumping, then I'm content.  The callback method described in the js-interop package docs looks fine to me.

</two-cents> 

[kc]

A catch 22.

The output of dart2js is hairy and complicated compared to CoffeeScript/TypeScript/Haxe - puts developers off.

Thus not enough developer demand is generated for the native DartVM in Chrome/Android.

Though if the DartVM is very popular on the server - node style - that could generate interest.

The thing that would really generate interest from developers is *commitment* from Google that the VM is going into Chrome and Android - and will give a fast and fluid touch experience on both platforms. Developers need direction from Google.

K.

[Don Olmstead]

I don't honestly understand why web devs are put off by what the compiled output looks like. I've had this conversations with web devs and it boggles my mind. I'm guessing it was the same when C came around and started producing assembly, and the assembly guys were like "I can write better assembly than that." and made a big stink.

My main complaint was it wasn't possible to just use the Dart library in a JS program. @Jim Trainor hows your experience with the JS calling Dart side?

[mythz]

Agreed, IMO optimizing for readable JS is optimizing on the wrong thing, I would think the current focus of knowing that Dart2JS doesn't impose a significant perf penalty and is readable/debuggable with source maps is ideal.

[Jim Trainor]

I'm not at the point yet where I have to integrate my Dart and Javascript. It will be happening soon (next few weeks).  I'm going on the docs right now, and they provide a method so I'll go from there. Also, I'm in the camp that doesn't care what the compiled Javascript looks like. I just want it to be small and fast.  I have to debug the generated javascript every now and then and have never had a problem understanding what I'm looking at. Source maps are generated to make it even easier if/when one has to debug the generated Javascript - you can look at your original dart code.  The only times I have to debug the javascript are when the Dart VM and Javascript differ - which doesn't happen too often for me.

On Monday, May 6, 2013 8:22:51 PM UTC-4, Don Olmstead wrote:

[David Mouton]

Neither the size nor the aspect of Javascript has no importance for me either.
We can simply consider it as the language of a VM. In this context, two things remain important, compatibility and performance.
I know nothing on the performance of code generated by dart2js. Unfortunately I'm having trouble to run it in a Web Workers for example.

This makes me think that Dart is not enough mature to be used instead of JS.
Typescript is a promising but still very young technology.

And I'm not talking about PlayN, PlayScript nor RandoriJS able to cross compile C #, Java and AS3 to JS.

Many developers are looking for a way to use modern,class based langages, instead of a poor prototyped langage.

If this is your case, you should have a look on Haxe.

2013/5/7 Jim Trainor <jim.train...@gmail.com>

[Xavier M.]

Hi David,

Typescript is a promising but still very young technology.

Young but fully functionnal and efficient... The only point I don't like yet (but the typescript team is working on it) is the modularization which is imo highly perfectible. All other features are effective, even IDEs (jetbrains, VisualStudio, CATS).

It is really enjoying to write nice code (for an OO guy) and be able to use backbone, jquery, bootstrap, domojs, transparency, and so on ... without pain..

best regards

Xavier

[David Mouton]

Completely agree with you.
The youth of typescript is mainly a barrier to its adoption in the enterprise.

2013/5/7 Xavier M. <xavier...@gmail.com>

--

[Xavier M.]

yep, as dart :) or gwt at the beginning... But the risk is quite low knowing that the generated code is highly readable ...

2013/5/7 David Mouton <da...@tamina-online.com>

--
Bien cordialement,
Xavier

[Mike Watson]

So, what's the Dart plan? Dart's developers decided to provide two scenarios for Dart use. These scenarios are not equally exciting or equally likely. In one scenario, browser creators support the Dart virtual machine, allowing you to write native Dart code both server side and browser side. This lets you create large-scale, full-stack Web applications that run lightning fast. 
That's a pretty cool idea. But, that's not going to happen.
http://www.drdobbs.com/web-development/can-googles-dart-hit-its-target/240153181

Dart and TypeScript are probably going to my main client side tools. I don't even worry about the Dart VM anymore because it's likely got as much future on the client side as the Java VM, Silverlight or Flash. 

The Dart server team seems to be going after the NodeJs crowd and I wish them well.

Dart isn't faring well in the browser client language hit parade. (Haxe is from the gaming community and seems too be good for ActionScript devs)

http://altjs.org/

but that's ok, I like it well enough to keep using it for the right circumstance. 

Mike

[Bob Nystrom]

On Tue, May 7, 2013 at 10:06 AM, Mike Watson <michael...@gmail.com> wrote:

Dart and TypeScript are probably going to my main client side tools. I don't even worry about the Dart VM anymore because it's likely got as much future on the client side as the Java VM, Silverlight or Flash. 

I think there are a surprising number of places where a fast VM could find a happy home. Even if the Dart VM doesn't end up in Firefox or IE, the VM can still be an entirely successful and useful part of the Dart ecosystem.

1. Even if shipped apps don't rely on the VM, having it in Dartium is a huge productivity win for development and debugging. No compile step, no source map weirdness, just refresh and debug straight code goodness.
   
   
2. Most apps will work just fine both on the VM and compiled to JS. So here the VM is just a performance bonus for the users that happen to choose a browser that supports it.
   
   
3. Some apps are, by design, limited to certain runtime environments. If you're making a Chrome app, it doesn't really matter to you if Firefox doesn't have the Dart VM.

And, of course, there are other ideas that I wouldn't want to speculate on but that could be awesome.

 

but that's ok, I like it well enough to keep using it for the right circumstance. 

That's what matters the most!

- bob

[Michael Watson]

Exactly, and I agree with everything you said. 1) is a huge dev time saver. The fast write/run/debug is a huge time saver. If I had a blog I'd probably write a post "How I stopped worrying about the Dart VM and learned to love Dart!"

I also support what the Dart team is doing on the server. Given what Lars Bak has said about "broken" JavaScript, it probably doesn't sit well that V8 is used in NodeJS and it's become so popular. Dart and the Dart VM is an answer to that. I don't do a lot of server side stuff (so far), but it's great that both Dart and TypeScript are targeting client and server.

--

[Matthew Butler]

In addition to Bob's comments... I see it as fairly likely that the VM Will end up in other browsers. Now it won't happen tomorrow, or anything close. But one of the reasons others have chosen not to have Dart VM is because it's proprietary... which is sort of true. It is open sourced. But beyond that, some members of the Dart team have already said that the plan is to submit the language for standardization once it is developed to a satisfactory point. 

Secondly, Chrome itself is generally the largest market share of browsers. Lets assume that once stable Google will invest in its own product and implement the VM in Google Chrome (again not until its stable). Well suddenly Chrome has the Performance increase of snapshots (plus the VM itself). If its significant enough this will either 1) Increase Chrome's market share even further because of the speed increase people notice on some sides (developed with Dart), or 2) Other browsers feel the urge to keep up with Chrome and implement the VM (again once it has become an Open Standard, but certainly not before). 

In either case, even if it only ends up in Chrome, the VM can provide 30-40% of your page viewers a significant speed increase simply by including the .dart files in addition to the Javascript you've compiled. In the mean time, I don't think the VM is something to disregard in any picture of the future web.

Matt

[kc]

On Tuesday, May 7, 2013 7:26:43 PM UTC+1, Matthew Butler wrote:

In addition to Bob's comments... I see it as fairly likely that the VM Will end up in other browsers. Now it won't happen tomorrow, or anything close. 

That seems unlikely! Dart seems a bit insular. Strongtalk in Java drag. Maybe Google should have forked Haxe or another compile to JS/Java language. And collaborated more. 

Dart's fate largely depends on what happens with ES6. If ES6 is signed off with modules/classes/let/const and other good stuff - it will be pretty compelling for dev's who want more structure. But if ES6 goes the way of ES4 - then maybe developers will give Dart another look out of sheer frustration. Especially if Google put the DartVM into Chrome and Android.

K.

[Don Olmstead]

I've always argued that the real target for Dart is native application developers who want to turn their attention to the web. Anyone brought up on JavaScript is going to have minimal interest in Dart, but people who have a C/C++/C# background look at JavaScript and cringe. Dart is also very attractive to game developers because it looks enough like the code they're used to seeing, it is faster than JavaScript and even has SIMD support, and its not JavaScript. I've honestly heard little mention of HaXe but know of game developers using Dart or expressing an interest in it.

--