Live data from Hacker News

Why Dart should learn JSON while it’s still young

maxhorstmann.net

41–50 of 55 posts

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

#41
post #38

Earlier quoted context omitted.

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.

And under modern Smalltalk do you imply modern Java?

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

#42
post #31

Dart is actually trying to teach the web about static typing.

Static typing is not incompatible with JSON serialization, if done properly. It sounds like Dart's semantics are the problem here (and since they've reached 1.0 they can't fix it).

Dart effectively has very little static typing anyhow.

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

#43

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"); >…

With enough static typing, or some sort of schema, none of this is a problem: all you need to do is to specify the type you're deserializing to. That said, it sounds like Dart is in trouble here due to other problems with its design (inheritance).

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

#44

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

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

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

#45

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"); >…

With enough static typing, or some sort of schema, none of this is a problem: all you need to do is to specify the type you're deserializing to. That said, it sounds like Dart is in trouble here due to other problems with its design (inheritance).

Well, there is a language that's perfectly suited to JSON serialization, and it has inheritance but not static-typing.

The point here is that designing a language around the current fashion in serialization is a bad idea. The problem as laid out in the article is unsolvable. A serialization format can automatically capture the semantics of a given language's native data structures, or it can easily interoperate with other languages, but not both.

JSON hits a sweet spot on the web because it captures a large subset of Javascript's data structures, while being simple and inflexible enough that other languages can work with it via libraries.

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

#46
I was recently writing a JSON un/serializing component in TypeScript, which is much nearer to JavaScript than Dart I believe, and even though I just had to make it work with a few certain types I knew in advance, it was still a PITA. I don't think there's a good way to JSON-to-anything-serializing, you always end up with some type related "tags" which shouldn't really be in the JSON data.

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

#47

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

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

#48
post #41
post #38

Earlier quoted context omitted.

Dart is basically a modern Smalltalk looking for a market.

And under modern Smalltalk do you imply modern Java?

No, because Java isn't able to provide the type of dynamic enviroment coupled with live coding as Smalltalk does.

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

#49
Thanks, was thinking of delving into Dart, but between the mediocre JS interop and this, I decided not to. Not to mention that ES6 brings tons of goodies to JS too, and the speed difference is not that great anyways.

Great JSON integreation is one of the things I enjoy most from Javascript (well, it makes sense given the J in JSON).

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

#50
post #37

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

Reports of JS warts are greatly exaggerated. The two big remaining ones (post ES6) are type conversion by operators and silent failure when accessing object properties. Both are fixable with a nice type system with HM inference and structural types. I wish someone did JUST that, instead of trying to bring all the problems and warts of Java to JS while trying to fix it.

Roy looks very promising[1], and I'm hoping it will mature to the point where it can be considered a viable option for production projects

Typescript would've been ideal, but its kind of fake-open-source (no actual development can be seen on the repository, some of the code looks generated, no discussion about the internals or providing an API) and its moving towards having LESS type inference in the name of improving compiler speed, less type safety in the name of... "its too hard to do" I guess. And they still are not releasing anything which might help other vendors improve their tooling (e.g. Intellij IDEA, the second-best contender sucks at TypeScript). And the module system is a total disaster, especially if you're trying to do anything more complicated and CommonJS.

[1]: http://roy.brianmckenna.org/

Post reply on HN