5 ms·

I'm on the Dart team, so I'm extremely biased here :) but I think Dart has a very bright future. Many people seem to think that better performance is the main

I'm on the Dart team, so I'm extremely biased here :) but I think Dart has a very bright future. Many people seem to think that better performance is the main reason to choose Dart, which can be viewed in a positive or negative light, because a Chrome with the Dart VM could be great because of the performance gain, or terrible because it's bringing a "runs best in Chrome" world. So I like to say that better performance is just one reason to choose Dart, but that Dart brings many benefits over other languages (not just JavaScript) and so appeals to different developers for different reasons. A few examples: * Dart is very toolable and has a great IDE experience in a number of IDEs already: IntelliJ/WebStorm, Eclipse, the Dart Editor, Sublime, etc. * The semantics are much more sane and predictable than JavaScript: objects are closed; Dart has class-based inheritance with interfaces and mixins; type coercion is eliminated and thus predictable; arrays are real arrays, bound checked and can't have holes; 'this' is lexically bound; accessing a undefined property throws an exception rather than propagating undefined through your program; there are no top-level statements, so startup is predictable; and on and on... * Dart's syntax combined with interfaces allow for really great libraries, and Dart's core libraries and dart:html take full advantage of that. [] is separate from property access, so Lists, Maps, and Sets have nice-to-use interfaces. There can be multiple implementations of List, Map, etc. It's possible to write delegate/wrapper/proxy classes, etc. Dart's core libraries are a joy to use. * Static type warnings and checked mode helps developers write correct programs. Type checks really do find errors early and save users time. We see this internally. The syntax is much lighter weight than Java. While people claim it's Java-like just because we have types (though they're optional), that's really a nonsensical argument - Dart's more like Smalltalk :) Dart programs are massively less verbose than Java, and I cringe every time I have to write Java code even a little. So we're seeing increased usage internally even though the VM isn't in Chrome yet. The other advantages are huge and have enabled teams to deliver new apps at very fast rates. They're mostly internal for now, but we'll hopefully see more externally visible apps soon. Also, we've just begun the era of server-side Dart in earnest. That's a big area for expansion that will feedback on the web usage.

aliakhtar 12y ago
Is there any reason for a GWT developer to want to switch, either now or in future? Since GWT already provides all of those benefits with Java. The only reason for switching that I can see, is if Dart's performance becomes better. Edit: Also, for Java, you might wanna try an IDE like IntelliJ, which writes a lot of your code for you. Or Java 8, which makes things a -lot- less verbose.
- spankalee 12y ago
  First, I think GWT and the GWT team are awesome. They've created a great piece of technology that I've seen do some amazing things, especially with code sharing. But... I think Dart is just a much nicer language than Java. It's way more concise and quicker to prototype with due to dynamic typing. Dart also supports reflection, even though it's strongly discouraged for production it's great for getting starting on something very dynamic before writing Dart's equivalent of GWTs generators. Here's a few things I like better off the top of my head: - Types are optional - Fields and methods are in the same namespace, making tearoffs clean. - Getters and setters. No more getFoo() / setFoo() - Top level functions - Implicit interfaces. Every class also defines an interface. No more Foo / FooImpl just because someone _might_ want to implement, or just for tests. - Mixins - Constructor initialization is fixed - Named constructors - Named arguments - noSuchMethod() and Function.apply() - Lambdas and structurally checked function types (not every Java deployment has this yet) - No shared memory concurrency - Method cascades. - Better and more consistent core libraries. Fluent Iterable and Stream used everywhere. - Factory constructors - No more builder pattern (named arguments, factories, and cascades combine to make it not needed) - String interpolation - Operator overloading, including [] and ==. List and Map use [] and []=, not .get(), etc,. There's no .equals() you just override ==. - Source-code VM. Edit / refresh, and soon fix-and-continue hot swapping in dart2js. It adds up. If you look at a reasonably sized ported code sample, it _really_ adds up. It's not fun at all to go back to Java.
  - aliakhtar 12y ago
    All the things you've mentioned involving dynamic typing, are not really a benefit. I much prefer the compile safety of strongly typed languages. GWT 2.7 has the same edit/refresh cycle, by the way (compiles have been optimized so they only take a couple of seconds). Lambdas and such are going to be added soon with Java 8 support.
Pharohbot 12y ago
THe problems that Dart solves as of now will probably be fixed in ECMAScript6 and TypeScript as well. Also the speed of Asm.js being implemented into V8 will definitely boost V8's speed.
- spankalee 12y ago
  But the problems won't be fixed because fixing them would break most JavaScript programs. TC39 is not going to split [] from property access, or (or planning to, afaik) make undefined property access throw, or make method tear-offs have a lexically bound 'this' by default, or seal all objects by default, or fix for loop variable bindings, or remove == in favor of ===, or remove the type coercions, add .==/.equals and .hashCode() to all objects, allow any object to be Map keys, etc. Dart does way more than adding types. If ECMAScript changed all of that (and much more), it'd be a different language. It'd be Dart :)
spankalee 12y ago
I fail at HN formatting - I forgot lists were pre-formatted and that horizontal scrolling is annoying. Here's those points again: - Dart is very toolable and has a great IDE experience in a number of IDEs already: IntelliJ/WebStorm, Eclipse, the Dart Editor, Sublime, etc. - The semantics are much more sane and predictable than JavaScript: objects are closed; Dart has class-based inheritance with interfaces and mixins; type coercion is eliminated and thus predictable; arrays are real arrays, bound checked and can't have holes; 'this' is lexically bound; accessing a undefined property throws an exception rather than propagating undefined through your program; there are no top-level statements, so startup is predictable; and on and on... - Dart's syntax combined with interfaces allow for really great libraries, and Dart's core libraries and dart:html take full advantage of that. [] is separate from property access, so Lists, Maps, and Sets have nice-to-use interfaces. There can be multiple implementations of List, Map, etc. It's possible to write delegate/wrapper/proxy classes, etc. Dart's core libraries are a joy to use. - Static type warnings and checked mode helps developers write correct programs. Type checks really do find errors early and save users time. We see this internally.
networked 12y ago
Are you familiar with Haxe? Would you say that Dart and Haxe are in competition with each other? Here is what Haxe's DOM API looks like: http://api.haxe.org/js/html/Element.html http://api.haxe.org/js/html/Element.html.
- spankalee 12y ago
  Only vaguely. I've looked over the site a few times, but never used it myself. I've hard good things about it from other Dart teammates who've looked closer. At first glance it looks like the Element API matches JS (probably generated from IDL), so it's not improved like dart:html. For instance Element.children returns an HTMLCollection which is not an Array and doesn't have the [] operator.
billconan 12y ago
man, your document sucks!
- billconan 12y ago
  I mean look at this page: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart:html.KeyboardEvent#id_charCode https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... functions and properties are simply listed, with no explanation, example. I won't call this document.

aliakhtar 12y ago

Is there any reason for a GWT developer to want to switch, either now or in future? Since GWT already provides all of those benefits with Java. The only reason for switching that I can see, is if Dart's performance becomes better. Edit: Also, for Java, you might wanna try an IDE like IntelliJ, which writes a lot of your code for you. Or Java 8, which makes things a -lot- less verbose.

spankalee 12y ago
First, I think GWT and the GWT team are awesome. They've created a great piece of technology that I've seen do some amazing things, especially with code sharing. But... I think Dart is just a much nicer language than Java. It's way more concise and quicker to prototype with due to dynamic typing. Dart also supports reflection, even though it's strongly discouraged for production it's great for getting starting on something very dynamic before writing Dart's equivalent of GWTs generators. Here's a few things I like better off the top of my head: - Types are optional - Fields and methods are in the same namespace, making tearoffs clean. - Getters and setters. No more getFoo() / setFoo() - Top level functions - Implicit interfaces. Every class also defines an interface. No more Foo / FooImpl just because someone _might_ want to implement, or just for tests. - Mixins - Constructor initialization is fixed - Named constructors - Named arguments - noSuchMethod() and Function.apply() - Lambdas and structurally checked function types (not every Java deployment has this yet) - No shared memory concurrency - Method cascades. - Better and more consistent core libraries. Fluent Iterable and Stream used everywhere. - Factory constructors - No more builder pattern (named arguments, factories, and cascades combine to make it not needed) - String interpolation - Operator overloading, including [] and ==. List and Map use [] and []=, not .get(), etc,. There's no .equals() you just override ==. - Source-code VM. Edit / refresh, and soon fix-and-continue hot swapping in dart2js. It adds up. If you look at a reasonably sized ported code sample, it _really_ adds up. It's not fun at all to go back to Java.
- aliakhtar 12y ago
  All the things you've mentioned involving dynamic typing, are not really a benefit. I much prefer the compile safety of strongly typed languages. GWT 2.7 has the same edit/refresh cycle, by the way (compiles have been optimized so they only take a couple of seconds). Lambdas and such are going to be added soon with Java 8 support.

Pharohbot 12y ago

THe problems that Dart solves as of now will probably be fixed in ECMAScript6 and TypeScript as well. Also the speed of Asm.js being implemented into V8 will definitely boost V8's speed.

spankalee 12y ago
But the problems won't be fixed because fixing them would break most JavaScript programs. TC39 is not going to split [] from property access, or (or planning to, afaik) make undefined property access throw, or make method tear-offs have a lexically bound 'this' by default, or seal all objects by default, or fix for loop variable bindings, or remove == in favor of ===, or remove the type coercions, add .==/.equals and .hashCode() to all objects, allow any object to be Map keys, etc. Dart does way more than adding types. If ECMAScript changed all of that (and much more), it'd be a different language. It'd be Dart :)

spankalee 12y ago

I fail at HN formatting - I forgot lists were pre-formatted and that horizontal scrolling is annoying. Here's those points again: - Dart is very toolable and has a great IDE experience in a number of IDEs already: IntelliJ/WebStorm, Eclipse, the Dart Editor, Sublime, etc. - The semantics are much more sane and predictable than JavaScript: objects are closed; Dart has class-based inheritance with interfaces and mixins; type coercion is eliminated and thus predictable; arrays are real arrays, bound checked and can't have holes; 'this' is lexically bound; accessing a undefined property throws an exception rather than propagating undefined through your program; there are no top-level statements, so startup is predictable; and on and on... - Dart's syntax combined with interfaces allow for really great libraries, and Dart's core libraries and dart:html take full advantage of that. [] is separate from property access, so Lists, Maps, and Sets have nice-to-use interfaces. There can be multiple implementations of List, Map, etc. It's possible to write delegate/wrapper/proxy classes, etc. Dart's core libraries are a joy to use. - Static type warnings and checked mode helps developers write correct programs. Type checks really do find errors early and save users time. We see this internally.

networked 12y ago

Are you familiar with Haxe? Would you say that Dart and Haxe are in competition with each other? Here is what Haxe's DOM API looks like: http://api.haxe.org/js/html/Element.html http://api.haxe.org/js/html/Element.html.

spankalee 12y ago
Only vaguely. I've looked over the site a few times, but never used it myself. I've hard good things about it from other Dart teammates who've looked closer. At first glance it looks like the Element API matches JS (probably generated from IDL), so it's not improved like dart:html. For instance Element.children returns an HTMLCollection which is not an Array and doesn't have the [] operator.

billconan 12y ago

man, your document sucks!

billconan 12y ago
I mean look at this page: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart:html.KeyboardEvent#id_charCode https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... functions and properties are simply listed, with no explanation, example. I won't call this document.