Hacker News Reader

Wouldn't it be possible to add some kind of @json class annotation then, which cannot be combined with "extends" and dynamic types? I understand that serialization of inheritance trees and arbitrary data is a complicated problem. So why not allow a simple case first and continue from there?

I guess inbuilt json serialization of simple types would already cover alot of real world rest scenarios which most users care about.

does anything actually work with dart2js?

All I seem to hear is people complaining about it.

Given so little effort is given to it, I halfway think they should just give up on javascript and javascript interop completely and focus on making dart awesome.

Anyhow, what you say is totally true, but surely iterating recursively over an object and dumping values into a json block would be trivial.

The hard part is deserializing that back into objects, but maybe you dont need to? The python json package does a pretty good job. You could just have it return a dynamic or something.

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.

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

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

> 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

Can you talk more about your experience with GWT-RPC?

GWT-RPC was designed before I got there, but the basic idea was to make it work just like Java serialization. To do this, you need to calculate at compile time which types the client might possibly have to deserialize and include client-side code to instantiate those types. But we don't want to do this for every Serializable type because of code bloat; when a type is declared Serializable in Java it's often intended for server-side serialization, not because anyone intended that type to be usable in a browser.

This is pretty hard to do in a language that supports both inheritance and generic types. Suppose you have a field of type List<Foo>. What values could the server possibly send the client?

- All subtypes of List: ArrayList, LinkedList. Also, ImmutableList and a bunch of other subtypes if Guava is in the classpath.

- All the fields in Foo, its serializable supertypes, and all its subtypes. And then do the same calculation again for those types, recursively.

Or if Foo is a widely used marker interface, anything implementing that marker interface in any library could possibly be sent. At this point, probably nobody working on the app has a good idea on why a particular type is included in the app.

Of course you could tell people to tighten up their type declarations. For example, never use List in a DTO; instead use ArrayList. This doesn't work because it just takes one field declaration in one library to screw it up, so it's hardly worth doing.

And I haven't even gotten into the complexities of things like:

class Foo<T extends Something> extends Bar<T>.

I heard a rumor once that someone proved that doing the calculation "properly" was NP-complete. In practice, we use approximations and there are bugs, though mostly people don't run into them too often.

I think it makes more sense to generate serialization code from an IDL such as a protobuf declaration. Since there's no inheritance and no generics, it's clearer to everyone which fields can possibly be transmitted on the wire and what the semantics are for forwards and backwards compatibility. Or just write out the JSON serialization for each class; it's not that hard, just repetitive.

Just remembered this thread and came back. Thanks for the insight.