Dart is actually trying to teach the web about static typing.
Why Dart should learn JSON while it’s still young
31–40 of 55 posts
Re: Why Dart should learn JSON while it’s still young
#32This 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?
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. 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 extends Bar.
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.
Re: Why Dart should learn JSON while it’s still young
#33Earlier quoted context omitted.
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 neede…
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
Re: Why Dart should learn JSON while it’s still young
#34This 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…
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.
Re: Why Dart should learn JSON while it’s still young
#35Earlier quoted context omitted.
> 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 th…
- 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…
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.)
Re: Why Dart should learn JSON while it’s still young
#36Earlier quoted context omitted.
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 neede…
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 y…
> 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.
Re: Why Dart should learn JSON while it’s still young
#37Personally I only care about JavaScript and am looking forward to ES6.
I don't care about transpilers and still looking for a use case worthwhile for Dart.
Unless Google pushes it, for example as Android language, ChromeOS or whatever might be the language killer application.
Re: Why Dart should learn JSON while it’s still young
#38Dart should be JavaScript. Seriously, what's the point of Dart again?
I think they just mess it up with the marketing of it.. but the technology per-se is very good.. and if you try to see it not as a contender to any other technology like javascript.. but just as another player out there to create programs.. there's nothing wrong with it.. People tended to be very sentimental about it.. because they see as a threat to javascript, as something that came to replace it.. and thats what w…
Dart is basically a modern Smalltalk looking for a market.
Re: Why Dart should learn JSON while it’s still young
#39Personally I only care about JavaScript and am looking forward to ES6. I don't care about transpilers and still looking for a use case worthwhile for Dart. Unless Google pushes it, for example as Android language, ChromeOS or whatever might be the language killer application.
I know ES6 brings a lot of new shiny to the table, but JS is a poor language. It's riddled with traps and interesting stuff, and you have to put up with excessive differences between browsers. It's just stuff like
Object.prototype.hasProperty.call(my_object, "property");
{
foo: 1,
bar: 2,
baz: 3,
}
I'm not sure Dart is the answer, but I welcome some competition. I think I'd be really interested to see a browser VM that languages could compile to, which would open the door to many languages. (I suppose asm.js might argue that they're this, and there is LLVM.)
Finally, I leave you with [1].
Re: Why Dart should learn JSON while it’s still young
#40Personally I only care about JavaScript and am looking forward to ES6. I don't care about transpilers and still looking for a use case worthwhile for Dart. Unless Google pushes it, for example as Android language, ChromeOS or whatever might be the language killer application.
I know ES6 brings a lot of new shiny to the table, but JS is a poor language. It's riddled with traps and interesting stuff, and you have to put up with excessive differences between browsers. It's just stuff like Object.prototype.hasProperty.call(my_object, "property"); or not doing { foo: 1, bar: 2, baz: 3, } or the truth table, things like `{} + []` and `[] + {}`, the insane implicit line joining… the list goes on…
> I know ES6 brings a lot of new shiny to the table, but JS is a poor language.
When started working professionally there was no web. So I do know JavaScript since the LiveScript days.
I never work alone, so I only care for languages ALL team members know, have proper support at the browser tooling[0] and are allowed to use by the customers.
For web development JavaScript is the only one that fullfills those requirements, so I don't care about anyhing else.
[0] good luck with source maps on mobile platforms