Why Dart should learn JSON while it’s still young

Scala learnt XML while it was still young, when XML was just as popular as JSON is now, yet incorporating XML into the language is now considered a mistake.

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 be worked out, though. Maybe put an annotation on the customer class to tell the compiler to save the original field names?

But a second issue is how it works with inheritance, including mixins. If a class is serializable, does that make all the superclasses and subclasses serializable as well? JSON doesn't have a standard way to represent a type tag, so does that mean we should invent one? If we do that, what happens to JSON interop with other languages?

Also keep in mind that Dart supports types that don't interop with JavaScript like unlimited precision integers. (Well, okay, that only works with the Dart VM, not dart2js...)

It gets worse. What if your class has a field type like List, which could contain any object? Does that mean the Dart compiler now has to preserve all symbols because any class could be serialized? And keep in mind that with optional types, all lists should behave the same when not in checked mode.

Having seen the mess that resulted in GWT-RPC, I would recommend just saying no to default serialization. Serialization and object inheritance don't really mix well which is why specs like JSON and protobufs don't support it.

(And now you know why language designers don't throw things into a language just because it seems like a good idea at the time.)

- 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: x =~= JSON.decode(JSON.encode(x)). (where x =~= y means that the two objects are Json-equivalent).

- The Dart-Editor already provides a quick-fix to write a toJson for you. To be honest I'm not really a fan of it, since I believe that serialization information should be outside the object, and not in the object (that's what "toEncodable" is for), but that's another story.

- It's extremely easy to get the behavior you want. Just use (or write, if none exists yet) a package that has your intended behavior. This is really a one-line change... This way you pay the price when you want to, and don't force it on all users.