Wishlist for 1.10 version!

[Rat Jo]

Here it is!

- What is your wish for the next release of Dart?

- Better editor? Missing functionnality in it?

- Is the language complete enough for you?

- Better integration with Android?

- There is a new Chrome Dev Editor, should it replace the current Dart Editor? (https://github.com/dart-lang/chromedeveditor)

Wishing you the best wishes :)

[Filipe Morgado]

I would love new language features but right now I feel it's the platform that needs more graps.


Android/Chrome integration is the bare minimum, and I'm not talking web/DOM, it's just too "battery draining" to say the least.

I wish Dart would get anywhere Adobe Air is. Efficient and focused graphics (and efficient OpenGL wrapper) and native IOS compilation. That would get us everywhere.

[Filipe Morgado]

(as long as server-side keeps getting some love, loving 1.9 so far)

[Kirth Gersen]

my wish list:

- github integration in the Dart Editor or make Chrome Dev Editor as powerful as current Dart Editor.

- fix Websocket in Isolate in Dartium (and these others 'dart:html parts' not supported in Isolate issues) or provide a way to debug dart2js code from the Dart Editor. More generally fix what work in dart2js but not in Dartium so we have complete equivalence.

- "real shared network sockets" server side so we can 'fork/spawn' an isolate to handle each new connection for instance (and not at the "bind" level like it's done in 1.9, it's very oddly done).

- more generally: more fixes and enhancements for Isolate and parallelism. We need easier ways to benefit from all these CPU cores in modern hardware both client side and server side. So may be add parallelism annotations or constructs to the language or do stuff at compile time, etc

and more importantly keep the good job and the fun 

[Bluenuance]

single wish:

-starting an Isolate with the possibility of doing HttpRequests inside

(k, this would be nice too:)

-improve editor stability

[Bob Nystrom]

On Wed, Apr 1, 2015 at 4:54 AM, Bluenuance <manuel....@gmail.com> wrote:

single wish:

-starting an Isolate with the possibility of doing HttpRequests inside

-improve editor stability

You said only one wish! That's two! :)

- bob

[Günter Zöchbauer]

starting an isolate and doing http requests are already two ;-)

[Benjamin Strauß]

Although i know this would rather be something for version 2.0 - mirror builders. :)

[Alan Knight]

The isolate with HttpRequest may happen. It works in JS now, but Dartium isolates are not workers.

On Wed, Apr 1, 2015 at 4:54 AM Bluenuance <manuel....@gmail.com> wrote:

single wish:

-starting an Isolate with the possibility of doing HttpRequests inside

-improve editor stability

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Justin Fagnani]

On Wed, Apr 1, 2015 at 12:35 PM, Benjamin Strauß <benm...@gmail.com> wrote:

Although i know this would rather be something for version 2.0 - mirror builders. :)

Mirror builders aren't necessarily a breaking change, so they wouldn't require v 2.0. They would only work in the VM however, and it'd be better to have a meta-programming solution that works with dart2js, so we'll hopefully see something else first.

[Don Olmstead]

I would like to be able to have a polymer element written in dart that could just be used in another web page without requiring them using dart.

[ravi teja]

+1 for Don's suggestion.

Ability to use Javascript output from Dart2Js just like another Javascript library from other Javascript projects without js interop.

[ravi teja]

Might not be related directly to Dart as a language but native Dart implementation of Core and Paper elements so that we can extend them and make our own custom elements.

[Günter Zöchbauer]

+1

but I guess this doesn't make much sense before they are stable in Polymer.js

[Jos Hirth]

- Int enums (like TS).

- Less stupid ternary (like TS). http://dartbug.com/22750 (closed, "AsDesigned")

Right now, "int x = foo ? 'olol' : 42;" is totally legit. It shouldn't be. You can't do that with if/else.

On Wednesday, April 1, 2015 at 3:46:04 AM UTC+2, Rat Jo wrote:

[Benjamin Strauß]

Am Donnerstag, 2. April 2015 08:21:39 UTC+2 schrieb Jos Hirth:

- Less stupid ternary (like TS). http://dartbug.com/22750 (closed, "AsDesigned")

Right now, "int x = foo ? 'olol' : 42;" is totally legit. It shouldn't be. You can't do that with if/else.

int x = 'olol';

is legit code. 

[Günter Zöchbauer]

Only in production mode and the analyzer would complain in DartEditor.

[jm]

Now that Dart is "free", "unplugged", "a new man, thanks to you mister Anderson", I presume it'll soon be able to compile to LLVM, JVM, PNaCl, right? 

That would be worth the Chrome bailout. 

[Benjamin Strauß]

Am Donnerstag, 2. April 2015 14:31:20 UTC+2 schrieb jm:

Now that Dart is "free", "unplugged", "a new man, thanks to you mister Anderson", I presume it'll soon be able to compile to LLVM, JVM, PNaCl, right? 

That would be worth the Chrome bailout.

you forgot the DLR ;). 

[José David Aroesti]

If Dart could have a command like "compass watch" (pub watch?) that automatically compiles dart code in the background to enables fast development cycles I would be very happy (of course not for 1.10). If there is a way to natively call and import jsObjects and functions (I would give away static typing for this surprise ;) ) I would be in heaven (something like, from '/lib/assets/my_js_lib.js' import MyJsObject).

[Jos Hirth]

On Thursday, April 2, 2015 at 12:10:50 PM UTC+2, Benjamin Strauß wrote:

It's about the analyzer. Currently, it only complains if both types are wrong and it thinks everything is fine as long as either sub-expressions yield the right type.

This behavior isn't useful. In fact, it's so undesirable that the ternary-if can be considered to be one of Dart's Bad Parts™.

Without tests which exercise both sub-expressions, you can't be certain that it won't explode in checked mode. It's true that this will be ignored in production mode, but if your code violates the "contract", it's obviously not doing the right thing.

I stumbled over this a couple of times when I ported some JavaScript code. It was really annoying.

[Haad Code]

- Hot-swap of code (browser preferred but Dart VM support would be enough)

- Single-file libraries, ie. ability to compile a package to a minimized, single-file, distributable .dart (or .js) file

- Ability to turn off tree-shaking in dart2js or fixing MirrorsUsed for dart2dart

These are all issues preventing us to push our Dart code to production.

On Wednesday, April 1, 2015 at 3:46:04 AM UTC+2, Rat Jo wrote:

[DoHyung Kim]

Considering the recent announcement that no Dart VM will be in Chrome, the most urgent thing to do is, IMHO, getting far better JS interop. For the vision of Dart VM in browsers, Dart had been stuck in its own island. It must change first.


2015년 4월 1일 수요일 오전 10시 46분 4초 UTC+9, Rat Jo 님의 말:

[Jim Trainor]

I'm curious what problem is not addressed by the current javascript interop package (dart:js)?

--

[Justin Fagnani]

On Fri, Apr 3, 2015 at 11:01 AM, Jim Trainor <jim.train...@gmail.com> wrote:

I'm curious what problem is not addressed by the current javascript interop package (dart:js)?

dart:js has four big issues for me:

1) It's low-level and has a cumbersome API: myJsObject['prop1'].callMethod('foo', [arg1, arg2])

2) Because of the Map-like API, it gives no help to tools: (No type annotations, type-inference doesn't work, bad code generation, no code-completeion, etc)

3) It introduces a layer of wrapper Dart objects around the JS objects

4) It provides very little help with exporting Dart APIs to JavaScript

Really great JS-interop would address all that by allowing you to simply define a Dart interface for a JS object, much like TypeScript, and maybe even consuming TypeScript .d.ts files. JS objects would not be wrapped, tools could reason about their types. Dart libraries and objects should usable from JS, ideally with no wrapping either.

[Jim Trainor]

I like the idea of the defined dart/js interface.  Doesn't seem too hard to implement on top of dart:js.

p.s. I have a simple solution I use today for exposing dart functions to js: https://pub.dartlang.org/packages/js_bridge. Works fine for simple cases.

[Justin Fagnani]

On Fri, Apr 3, 2015 at 12:24 PM, Jim Trainor <jim.train...@gmail.com> wrote:

I like the idea of the defined dart/js interface.  Doesn't seem too hard to implement on top of dart:js.

You can do it, and I did with package:js, but it's not nearly a good enough developer experience and involves way to much wrapping to be fast enough. Now that js-interop can optimize for dart2js/ddc a lot of the constraints that made that version of package:js not great are lifted and something much better can be done. 

p.s. I have a simple solution I use today for exposing dart functions to js: https://pub.dartlang.org/packages/js_bridge. Works fine for simple cases.

Interesting. dart:js also works for simple cases. What does this do that js.context['myDartFunction'] = myDartFunction; doesn't do?

[Jim Trainor]

js_bridge takes care of js'ifying arguments on the way in and out, it puts the functions inside a named "namespace" (just an object) on the javascript side, and it wraps the incoming calls in a zone.  Other than that, not much. 

[DoHyung Kim]

I was a first-time poster to this list. So it got too much time for my post to get through to this list.
Anyway, it seems that Justin stated what I had in mind.

1. Reduce any performance penalty

I don't know much about the dart2js implementation of dart:js package, and Jim's opnion seems that the current implementation doesn't cause too much overhead. But I've read https://github.com/cleandart/tiles/wiki#about-tiles and has been thinking Dart-JS boundary crossing is quite expensive. If I'm wrong, then this wish item can be ignored and the other items may be implemented atop dart:js package.

What I have in mind is dart2js should be involved deeply to generate JS bridge codes that can be optimized enough by modern JS engines.

2. Higher level JS interop

The integration with JS would be better if higher level than what it is. JS code would be directly embedded inside Dart function/methods. JS objects are imported as Dart objects. Maybe TypeScript type defnitions may be leveraged in the course.

3. Bi-directional interop with JS

It would be good to have JS access Dart codes, too.

That's all for now.

2015년 4월 4일 토요일 오전 3시 1분 45초 UTC+9, Jim Trainor 님의 말:

[Jim Trainor]

1. Performance is about 2us per function call, more as the complexity of the arguments increases.  Seems fine for a web application. 

2. Agreed on better integration between the two.

3. It's possible to call Dart from JS now.  But that access is limited to calling functions.

[DoHyung Kim]

Dear Jim,

IMHO, 2us per function call may not be enough for some use cases. I suspect that the current dart:js implementation contain megamorphic callsites, which are difficult to be optimized by modern JS engines. I think it would be better to introduce higher level JS interop directly baked into dart2js. Having dropped the plan to ship DartVM in Chrome, browser-side Dart should not be restricted by Dartium, where two VMs coexist with a rather wide river between the two.

Just my 2cents.

- DH

2015년 4월 4일 토요일 오후 5시 17분 45초 UTC+9, Jim Trainor 님의 말:

[Ron Gonzalez Lobo]

Hey there,


What do you think about a shorthand form of the ternary operator:

var a = 0;
var b = 1;

b = a == 0 ?: 1;

If the test expression evaluates true in a boolean context, its value is returned. Otherwise, the alternative is returned instead.

Thoughts?

[Jim Trainor]

If 2us per call is too slow then my question is: what's the overhead of a plain javascript function call?

I believe that dart:js when compiled to javascript (dart2js) simply turns into a javascript function call - so that's near "native" javascript performance.  I'd have to double check that be sure.  It wasn't that way, for example, in the original js_interop package which was, indeed, really slow.

A dart call to javascript performed using dart2js output is 1.3 us to be exact, as measured by my own benchmark: https://pub.dartlang.org/packages/js_bridge

[DoHyung Kim]

Jim,

BTW, I checked your work on js_bridge before writing my previous post, and read the numbers you produced. I'm impressed.

But per-call overhead of 2us doesn't seem the best we can get from the modern JS engines. At least, simple function calls in JS must be far faster than that. As far as I know, Java has single digit ns overhead per-method call. Even slower JNI invocation requires two digit ns overhead. (Yes, I'm a Java guy. ;) )

I guess the current dart:html implementation for dart2js uses something different from dart:js underneath, which is more performant. I think such a facility can be exposed to the public, considering we won't have DartVM on client-side.

What if I need to access fairly new JS APIs from my Dart code, and it is difficult or impossible to arrange the codes to require less boundary crossings? Definitely the boundary crossing tax must be lowered.

The boundary crossing overhead is quite a concern in other languages too. For example, JVM's JNI overhead and Go's cgo overhead. I think assuming Dart is transpiled to JS, interoperation with JS should be more like Scala on JVM rather than C functions with JVM.

Thanks.

- DH



2015년 4월 17일 금요일 오전 1시 7분 43초 UTC+9, Jim Trainor 님의 말:

[Jim Trainor]

dart:html is totally unrelated to dart:js. In the VM dart:html calls bind to "native" browser call that are somehow bridged from the VM - you can see that in the dart code itself, and you see it in the debugger. But that's mute at this point anyway for all but development in Dartium.  In dart2js it turns javascript call like any other.  Getting off topic.

As far wish list items go, I'm totally happy with performance. I value the software engineering capabilities of Dart far more than issues of performance (because it's "good enough"). Catching up with the latest polymer release would be my wish.

[DoHyung Kim]

It seems that we are saying under different assumptions. My points go like this:

• If the original plan of shipping DartVM with at least Chrome was still intact, I am definitely ok with the current dart:js. I fully understand bridging two different VMs imposes much restriction and dart:js is near the best we can get, and having more performant (if ever possible) dart:js only for dart2js doesn't too much make sense.
  
• So I'm assuming that it is possible to ignore Dartium in the near future. In that regard, maybe I'm making assumptions without a firm evidence.

As such, I'm assuming dart2js only future (if this confused you, sorry). And considering dart2js implementations of dart:html, dart:core, etc. have internal facilities for faster call into JS, I thought it was better to get the facilities out to the public. I also value the productivity boost Dart brings, and fortunately my current project isn't hit by dart2js performance. So I'm happy with what we have at least for now.

As I kept stating, just my hope. I think made my point clearer, and will stop here on this topic.

Thanks. It was very informative discussion.

2015년 4월 17일 금요일 오후 7시 1분 43초 UTC+9, Jim Trainor 님의 말: