Live data from Hacker News

Why Dart should learn JSON while it’s still young

maxhorstmann.net

11–20 of 55 posts

Re: Why Dart should learn JSON while it’s still young

#11

I was the TL of the libraries for almost a year, and there are good reasons we didn't go this route: - it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead. - it doesn't make sense to automatically encode elements that cannot be decoded. You should have…

Where is toJson in the Dart Editor? (I'm looking for it in 1.1.1, but couldn't figure it out.) And does it have a fromJson generator too?

Re: Why Dart should learn JSON while it’s still young

#12
It's the type data that makes this hard: JSON has no support for encoding new types into the serialization. This is a blessing and a curse: it makes JSON simple, but also inflexible.

Take this parting remark:

> So, here’s another thing I wanna add to my suggestion: consider adapting ISO 8601 for a default JSON serialization of DateTime, so the following just works:

> var dt = DateTime.parse("2014-01-26T11:38:17");

> print(JSON.encode(dt));

Ignoring the fact that it's a simple value you're attempting to encode to JSON, let's say this works. Do you get:

  "2014-01-26T11:38:17"
Now do to the reverse: what does that decode to? Either it decodes to a string, and you've lost the type information, or it decodes to a date, in which case, what does `JSON.encode("2014-01-26T11:38:17")` decode to? i.e., do strings sometimes decode to dates? What if someone uses what should be a string to cause the decoder to decode it as a date? Now anywhere you have a string, it might decode to a date!

YAML has support for this sort of thing, with a syntax like `!!date "2014-01-26T11:38:17"`. (If you want a literal `!!`, it's always `"!!"`.) Notably, the Python library for YAML can do what the author asks: encode and decode arbitrary objects. (but it turns out to be a security risk to do so on untrusted data.)

> The Dart editor should be able to display a JSON serialization of anything the mouse pointer touches.

If my class contains a file handle, what's the JSON representation of a file handle? Further, if I send that serialization across the wire, how do you deserialize it? I mention this because you can't, at least, not really. Python's `repr` is a good example here. When it can, it gives you close-to Python syntax for the object, such as strings (`"hello world"`), ints (`1`), decimals (`Decimal(3)`), etc. Perfect for debugging. For things it can't, you get something like `` — which doesn't parse (on purpose) as Python.

I'd venture to say that what you really want is the ability to introspect. Take your customer example: if you could introspect it, and see what member variables were present, you could build a function that might output:

  {"type": "Customer", {"Id": 1, "Name": "Joe Bob"}}
Again, note the explicit serialization of the type here, in JSON. This is something I made up, of course, and not JSON. Of course, some language feature can make introspection interesting. (Can you even get a list of members? Some languages allow objects to make up members on-the-fly.)

Hopefully, I've convinced you language design is hard. :-)

Re: Why Dart should learn JSON while it’s still young

#13
post #8

This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…

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.

Re: Why Dart should learn JSON while it’s still young

#14

Is there still people willing to use Dart instead of Javascript for web now? (no irony)

Yes. For some use cases the speed of development and rapid prototyping is worth it.

...but there are unavoidable severe limitations like slow js interop, large file size and poor browser compatibility.

Its really only plausible for very specific project where these arent issues.

Re: Why Dart should learn JSON while it’s still young

#15
post #8

This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…

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

Re: Why Dart should learn JSON while it’s still young

#16
post #11

I was the TL of the libraries for almost a year, and there are good reasons we didn't go this route: - it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead. - it doesn't make sense to automatically encode elements that cannot be decoded. You should have…

Where is toJson in the Dart Editor? (I'm looking for it in 1.1.1, but couldn't figure it out.) And does it have a fromJson generator too?

It was recently added, but apparently removed again. (I don't know the exact reasons).

Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QV...

Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425

Re: Why Dart should learn JSON while it’s still young

#18
post #8

This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…

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

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.

Re: Why Dart should learn JSON while it’s still young

#19
The problem with magic serializers is that they tend to be brittle in practice. This is because the assumptions they make don't work across languages.

For example, if you use a magic serializer, your properties might have to follow a different capitalization format than what's normal for your language.

Recently, I ported some Java code to C#. It was written with a magic JSON serializer. When I got to test my port, nothing worked! It turns out that Java's serializer used lowercase names in JSON, but my serializer used uppercase names! The magic, unfortunately, didn't work, because assumptions that were valid in Java did not carry over to C#.

I think it's best to think of magic serializers as rapid prototyping tools that work well when both ends are the same languages. Thus, while might be useful for Dart to include one very simple quick-and-dirty serializer to JSON, any production code of merit will most likely outgrow it.

Re: Why Dart should learn JSON while it’s still young

#20

Earlier quoted context omitted.

Yes. For some use cases the speed of development and rapid prototyping is worth it.

...but there are unavoidable severe limitations like slow js interop, large file size and poor browser compatibility. Its really only plausible for very specific project where these arent issues.

Dead code elimination and minification do a good job of reducing Dart2js file size. Dart converted to JavaScript works on IE9 and above and all other modern browsers. JsInterop is done through port send and recieve, so if you need to make a lot of those calls it is potentially slow, but if not, for example I'm making one call to PDF.JS, it works beautifully. Dart's real problem in my opinion is that many 10's (100's?) of nifty JavaScript libs are written everyday that won't work well with Dart. The JavaScript ecosystem just keeps getting better, while the Dart ecosystem plays catchup. Because of this I use TypeScript for some projects.
Post reply on HN