Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dart 1.5

news.dartlang.org

Post reply on HN
Print view View original

71–80 of 167 posts

Re: Dart 1.5

#71

Post by munificent »

msoad wrote: post #41
munificent wrote: post #35

Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.

Hi, I have two questions: 1. One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this? 2. Will we see another UI rendering layer other than DOM for Dart?

> 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.

[1]: http://www.infoq.com/presentations/dart-introduction

Re: Dart 1.5

#72

Post by mraleph »

azakai wrote: post #60
macspoofing wrote: post #51

Earlier quoted context omitted.

>As things currently stand, Dart compiles to JavaScript, which is exactly the right way to do it That was never going to change. The idea, as far as I understand it, is for Dart to be executed natively where there is a Dart VM. Where there isn't, the dart2js output would be executed. The DOM itself would be unchanged. I think that's reasonable. In fact, more than reasonable, that's just a good idea.

The danger is that the VM has different semantics (for example, integer overflow) than dart2js code. If the same dart code sometimes runs in JS and sometimes in the dart VM, people are going to hit weird bugs. Also, if it is possible to ship dart code by itself - without the JS fallback - then we are going to see sites that don't bother with the JS fallback, and those sites are only going to work in chrome. For both…

Here is a question to consider: can the web where you can't efficiently[1] implement any dynamic language with a semantics different from JavaScript be called truly open?

[1] I am well aware about different attempts to attack this issue from various angles from AOT to JIT generating JS code but no attempt currently produces truly efficient solution that demonstrates small footprint and consistent high performance on par with native VM across all of the web or even across its relatively modern part.

Re: Dart 1.5

#73

Post by timothya »

lmkg wrote: post #46
munificent wrote: post #35

Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.

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 Co…

You can read more about the JS-Interop support here: https://www.dartlang.org/articles/js-dart-interop/

Re: Dart 1.5

#74

Post by cromwellian »

josteink wrote: post #21
caycep wrote: post #12

This may be a noob question on my part, but my understanding is Dart and Rust are 2 separate efforts to come up with something to supplant javascript?

No. Rust is a systems language meant to displace c and c++. Dart is Google's me-too attempt at creating something which compiles to JavaScript. It borrows heavily from java and generates equally bloated code. OK, so maybe last sentence is a bit over the top critical, but last I checked, hello world in dart rendered in at 100kb [1] of js and dependencies. [1] http://lostechies.com/jimmybogard/2011/10/12/the-dart-hello…

If the Dart team decided to put a lot of effort into it, I bet they could get that down, but to what benefit? The average application isn't a hello world and so most of the code that isn't being pruned is likely system runtime code that most apps need.

I decided to try such an experiment with GWT recently, since the same kind of unfair microbenchmark has been used against it.

I detail how I reduced the hello world from 2205 bytes to 710 bytes here: Th3e Hello World Challenge https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS

What how did I do it? By not registering any global exception handlers, or any async tasks, and arranging for the compiler to be able to optimize away the unused runtime stuff.

But how likely is it that no one wants to catch exceptions and print pretty stack traces? Or to schedule microtasks to run at the end of the event loop?

It's not a realistic test.

Re: Dart 1.5

#75

Post by munificent »

pohl wrote: post #42
munificent wrote: post #35

Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.

Has there been much internal dogfooding, such that some external-facing thing I use is really powered by JavaScript that came out of dart2js? If I'm using GWT, should I be thinking about using Dart instead?

> Has there been much internal dogfooding

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.

[1]: https://api.dartlang.org

Re: Dart 1.5

#76

Post by munificent »

crncosta wrote: post #50
munificent wrote: post #35

Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.

Thanks for coming to answer questions. How this 1.5 release is related with the work in progress in the Ecma TC52 for Dart Standardization?

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.

Re: Dart 1.5

#77

Post by WorldWideWayne »

I just don't trust Google to do languages and developer tools very well. They don't seem to depend on developers enough to bend over backwards for us the way that Microsoft does.

Plus, they seem to want to use web tech to build native desktop tools all the time and little things like "keyboard acceleration" don't seem to matter to them because there are no standards for that in web-world.

Re: Dart 1.5

#78

Post by azakai »

macspoofing wrote: post #70
azakai wrote: post #60

Earlier quoted context omitted.

The danger is that the VM has different semantics (for example, integer overflow) than dart2js code. If the same dart code sometimes runs in JS and sometimes in the dart VM, people are going to hit weird bugs. Also, if it is possible to ship dart code by itself - without the JS fallback - then we are going to see sites that don't bother with the JS fallback, and those sites are only going to work in chrome. For both…

A lot of those objections could have been applied to SPDY, a protocol google developed unilaterally and initially was only supported in Chrome and Google sites. The end result was that everybody else got a regular experience while Google Service Chrome users got a better one. Other sites started including SPDY, and then browsers got in on it as well. Seemed to have worked out well. I don't see how Dart would be any d…

SPDY does have some similarities, but the differences here are very large.

As I said, Dart runs differently in the VM and in dart2js. SPDY was just not present in other browsers at first. So there wasn't a case of sites breaking in subtle and hard to debug ways in SPDY, but there is in Dart. (Later, when other browsers started to support SPDY, there were the usual spec issues, but that's a separate matter.)

The second issue I raised was that someone could ship Dart code alone, without the JS fallback. In that case, it is indeed more similar to SPDY, as someone could in principle write a SPDY-only website. Even here there is a difference, though - SPDY relies on client+server interaction. Dart is client-only (there's a Dart server, but that's not relevant here). Client-only code can more easily stay on the web for a long time, possibly forgotten and unmaintained. But this might be a small difference, so I somewhat agree with you on this point, but disagree on the previous.

Re: Dart 1.5

#79

Post by munificent »

pm90 wrote: post #66

How does dart compare to coffeescript?

This is a very simplified answer, but here's my take:

CoffeeScript says that the main problems with JS are the inelegant C-style syntax and a few semantic trip wires. It addresses those while still keeping the underlying semantics, APIs and ecosystem.

If what drives you up the wall about JS is stuff like the DOM, or JS's object model, CoffeeScript won't help you much. If you are OK with how JS behaves and like the very large JS ecosystem, CoffeeScript can be a nice fit.

Dart takes a much larger semantic step away from JS. Syntactically, it's more similar to JS than CoffeeScript is. It sticks with braces and statements, and the whole C kit and kaboodle.

However, semantically, it's much different. It has a full-featured class system with inheritance, mixins, getters, setters, operator overloading, etc. It has a static type system so you get the nice tooling experience you expect from a language like Java or C#. It also completely revamps the DOM APIs to (hopefully) be more rational, modern and consistent.

The cost, though, is that interacting with the existing JavaScript world is a little more difficult. You can interop, of course, but it isn't as seamless as CoffeeScript.

Re: Dart 1.5

#80

Post by jmesserly »

lmkg wrote: post #46
munificent wrote: post #35

Hi! I'm on the Dart team. If you'd like, I'll try to answer any questions you have.

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 Co…

> 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).

Post reply on HN