HN Explorer

Ask HN: Dart's Future

14 points by Pharohbot ↗ HN
What do you guys think about Dart's Future as a programming language of the web? I see a very bright future down Dart's long road but Im also kind of worried about many of the ignorant people's views about Dart(IE Java-like, made by Google, competing with JS(which it isnt)). if Dart is implemented to Google Chrome(Which is actually closer than you think) it will be a huge turning point for Dart and hopefully other browser vendors will follow the lead. There is nothing but good with Dart, its 2x faster than JS, it outperforms V8 JS engine and it has many packages being updated and created every day(see https://twitter.com/dartcode for automatic pub package updates). It wont replace JS, but it will be one of the big players(as it may be already) in web development. What do you think?

25 comments

[ 5.3 ms ] story [ 55.7 ms ] thread
xpto123
Unless other browsers support it via browser plugins, it could turn out to be a dead end, Google is betting on mutiple horses here because themselves cannot predict this.

Its also possible to compile Dart to Js and use it as an improved language for web development.

But the JS VMs are already very fast these days, so being the performance of Js VMs acceptable there is not much reason to go from Js to Dart.

I have the impression that Ecmascript 6 and Web standards like components, templates, imports and shadow dom are the future of the web, and not an alternative language.

All browsers are investing very heavily on that, in 2015 we should probably start having the first Ecmascript 6 compliant browsers.

ES6 seems to be the backwards compatible path of least resistance going forward, and that is the path that usually succeeds.

spankalee
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
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
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
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.
spankalee
None of the things I mentioned involve dynamic typing. Care to elaborate?
aliakhtar
> quicker to prototype with due to dynamic typing.

> optional types

etc.

solomatov
>Types are optional

For me, this is show stopper which negates all other stuff. After types are optional, then type errors turn into warnings, and you get the same mess you have in JS. Another annoyance is lack of real generics.

spankalee
It's not the same mess as in JavaScript because we have checked mode which enforces the types at runtime. Combined with the static warnings we find this to be very, very effective.

I hope you don't just leave warnings in your project :) but if during development you want to try some code path you're pretty sure will work while you have fixed up other paths that have warnings, you should be able to. The philosophy is to make as many errors happen at runtime rather than "compile" time so that you can continue to work with out always having to satisfy the type checker across your whole program. This is one of the productivity advantages of dynamically typed languages. We feel that the combination of dynamic types and checked mode gives you the best of both worlds.

aliakhtar
> The philosophy is to make as many errors happen at runtime rather than "compile" time

This is pretty terrible. I would much rather find out about errors at compile time. Its a lot easier to find the source of the error from within the IDE and fix it, than to debug a runtime error.

SteveMcQwark
I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code.

This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.

Pharohbot
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
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
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
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.
spankalee
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.

josteink
Dart is a Google-only dead end.

Even if Google supports it in Chrome, the other browser wont bother supporting it, and like spankalee says, it will then become another "runs best in Chrome" thing, and cement Chrome's position as the new IE.

I'm not sure if they want to do that, but Google's (mis)direction as of late means I'm not going to leave out anything.

spankalee
My point is that you don't need the Dart VM for Dart to be a great choice, which means that the lack of the VM in other browsers shouldn't be a problem.
horrido
In fact, it may be a very smart move for Google to mandate that Dart VM be NEVER incorporated into Chrome!
horrido
Google is sending out a rather confusing message: use Dart; use AngularDart; use JavaScript (AngularJS); use AtScript (AngularJS 2.0). How long before we see: use Golang? (There's already a Go2JS compiler.)

Also, if Chrome is the only browser to incorporate the Dart VM, the "works best in Chrome" attitude will annoy non-Chrome users, who will feel they're treated as second-class citizens. You hope other browser vendors will follow the lead? Dream on. Politically, it's not going to happen. Microsoft, Apple, and Mozilla will NEVER accept Dart.

I think Dart is an okay language. I might even use it someday. But I can think of alternative languages that are a lot more pleasant to use, eg: https://medium.com/@richardeng/js-christ-im-using-js-1d1d086...

horrido
It's worth noting that GWT is still in use today, even at Google. So add "use Java" to Google's confusing message. However, Google is probably not interested in promoting GWT anymore. Oracle's Java patents are a P.I.T.A.
jack1011
Well, i think dart is a great language, with many features. But I recently tried to build an app with it, and the real down side is, that every library out there needs to be ported to dart and maintained. Yes there are many updates on the libraries, but they mostly update to versions which are lot older than the ones released in Javascript. (e.g. Polymer: 0.5.2) The hard part is therefor to maintain the libraries of dart while the JS projects move on very quickly. So if u use dart you always have old libraries that will be used while there might be more possibilities with the js ones.