Hacker News Reader

Comment by floitsch | Hacker News Reader

Disclaimer: I'm the TLM of dart2js.

The dart2js team is one of the teams with the most developers on it. There is a huge effort going into it.

Dart2js generally does a good job, but a few features (like mirrors) that are still in beta-quality, are currently a constant source of grieve for the developers. We would have liked to delay their release until they were more stable, but several customers really, really needed them.

Things are getting better, though, and I hope that dart2js will fade into the background (as a simple working tool) soon.

View on HN

I understand you guys are working on it, and it's a tough problem, but for a flagship javascript drop in replacement isn't releasing something that griefs developers really bad?

Surely releasing a top quality library that works well is far more important than getting in early and releasing something that alienates developers and makes them try dart and them give up on it?

It's obviously your prerogative to do what you feel is best, but it's certainly not the choice I would have endorsed.

(I supposed the horse has bolted to a certain degree now, it's good to know that a lot of effort is being directed at dart2js I suppose, although from a developers persepective I don't really feel that it's particularly visible...)

> releasing something that griefs developers

Maybe you only see (and/or notice) people talking about corner cases that still need addressing (like azakai's sibling comment about the mapping of arbitrary precision integers to JS's number type)? For the vast majority of code, AFAIK, dart2js has no issues and emits good JS code.

I don't develop with dart, but I know a handful of developers that use dart2js to release their dart code on the web and it works just fine for them. mraleph just released IRHydra2[1], which is all Dart from top to bottom via dart2js and works really well (despite using the apparently still-nascent Dart port of Polymer).

If you have specifics, by all means, talk about them, but "All I seem to hear is people complaining about it" seems like really shaky ground from which to make comments about griefing and alienating developers.

[1] http://mrale.ph/blog/2014/01/28/prerelease-irhydra2.html

    - huge js file size (2MB+ easily)
    - obscure hard to use js interop facilities
    - very slow js interop
    - broken js minification (ignored tickets)
    - no older browser support
    - ridiculously long compile times

I honestly welcome anyone who uses dart in a production environment to link to a blog post or explain how they worked around these, because we found they made using dart2js such a nightmare we gave up on it.

I speak only for my own experience, perhaps others have different experience, but no one seems to have good things to say about the experience working with it that I can see...

(amusingly, from your link: 'Does not work in Firefox (neither Stable nor Nightly), but works in Chrome Dev and Safari.')

This isn't production, but I found dart:js to be pretty reasonable for interop with CodeMirror and a Chrome extension API. (I did find it better to send a batch to a wrapper function rather than making JavaScript calls in a tight loop, though.)

> (amusingly, from your link: 'Does not work in Firefox (neither Stable nor Nightly), but works in Chrome Dev and Safari.')

It's most likely problem with polyfills, not with dart2js compilation problem, I have not tried to debug it yet.

Fixed. It was purely my bug: I was relying on a certain ordering of propChanged() callbacks, but it does not seem like Polymer.dart guarantees any.

Now it works in Chrome/FF/Safari all the same.

This comment had me scratching my head. Right off the bat, if you need to run on older browsers, don't use Dart. It's not a secret. Use TypeScript instead. If you need to make a lot of calls into existing JavaScript libs to the point where speed reduction is noticable, don't use Dart. What's so hard to use about js interop? How is it obscure? Throwing out 2MB file size without stating the LOC of the original Dart source is meaningless. I've never noticed long compile times. I do my development in Dart, which runs almost instantaneously, then when all is well, I do a build which compiles and minifies which is reasonably fast. The only thing I can figure is that you're using Dart Polymer, which last I checked, was still in development. My single page app is approaching 10,000 LOC and minifies to about 295K, which is hardly too large. I'm using Dart as a straight replacement for JS and not trying to use the advanced language features, which my explain my more positive experience.

> releasing something that griefs developers

The belief that a programming language is persecuting you...this should be taken as a sign.

So, one thing that I should ask: have you ever designed and implemented a serialization format for an object-oriented language? There is a reason why JavaScript works so well with JSON.

Working with Smalltalk, Obj-C, Clojure, and many other languages besides, it's a fairly simple matter to use a library to do conversion. A few fun reflection tricks are usually enough to get you objects pretty quickly. Why this should be seen as a language issue is beyond me. It's a tool and library issue.

Is there a plan for fixing the behavior of integers so they are the same on the VM and dart2js?

If there is one it's not public. Here's the bug to track: https://code.google.com/p/dart/issues/detail?id=1533

Reply on news.ycombinator.com