Hacker News Reader

Comment by sethladd | Hacker News Reader

Dart is much more full-featured than CoffeeScript. Dart is a completely new language, with much improved semantics. Dart has features such as method cascades, mixins, async/await, optional types, a rich core library, factory constructors, libraries, named parameters, lexical this, Futures, implicit interfaces, generics, and lots more.

[disclaimer: I'm on the Dart team]

View on HN

I am not saying Dart and CoffeeScript are comparable in terms of features -- not at all, rather I am saying that both Dart and CoffeeScript have served similar purposes in showing where the JavaScript language can evolve towards in the future.

On the other hand, persuing the strategy that Google did with Dart distracted people and effort from the important task of actually improving javascript, so it may well have been a net negative.

If they'd succeeded in replacing it, there would have been no need to fix it. It's a big task, but I wish they'd succeeded and hope they (and/or others) try again.

Whether you like JS or don't, I think we can all agree that it stinks to have only one choice for client-side scripting.

ES7 has async/await. Coffee script has a tighter syntax despite being older than Dart. Typescript has optional types and is being used at both Microsoft and Google. Also: you don't think JS has libraries and mixins?

How about: "ES7 will most likely have async/await when it's finished."

Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

Also, pointing to features people can use in different dialects of JavaScript is not really fair. Just about everything you can think of has been experimented with and probably deployed somewhere. It doesn't count unless it's all available in the same toolchain and can be used in a unified way while writing a single app.

> Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

If that's the metric we're applying, Dart fares no better...

How so? You can use Dart today and yesterday and tomorrow.

In what browser?

Chrome, Firefox, Safari and even IE!

All via dart2js

Sure but you can also use es7 today (which I did).

Yes, and even compared to ES7, Dart still fares rather well. Most people that doubt this seem to not have actually tried the Dart workflow and core libraries. The productivity gain from those two features alone makes it compelling against all other compile-to-js options, because what it brings to the table isn't just a fancy language with nicer syntax+semantics.

The dart std lib, at least the DOM manipulation bits, are indeed nice.

OTOH: JS has the largest module system of any programming language ever, which also tends to make it pretty productive.

wycats: IE 10 and up, Safari 6 and up, Chrome, FF, Opera, last 2 versions.

> Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

ES7 async/wait is available now via the ES7 polyfill Babel.js: http://babeljs.io/

There are a ton of polyfills available right now for ES6/ES7 features: http://kangax.github.io/compat-table/es7/

BTW I also think that the current state of aggressive polyfills is also influenced by Dart's compile to JS functionality. :)

Comparing Babel.js to dart2js is fair. I'd be interested in hearing more about about how well it works in practice from people who use Babel.js for large apps. (Also, how does it compare to Typescript?)

Anyone creating a new Ember.js application today is using babel by default. It works very well in my experience. I haven't used typescript however.

I think with time Typescript and Babel.js are to be merged, if you through in Strong Script to the mix I guess you have the future of JavaScript.

Typescript has optical types

What are optical types? I've never heard of this term and Google turned up nothing on it.

100% sure it's a typo of "optional types".

How boring :-) I'd love to look forward to a language with optical types. I'm sure it's at least as interesting as operand overloading in Intercal.

I was imagining something like Lens in Haskell :)

Optical typing must be like duck typing taken to the extreme. If it looks like a duck then it's a duck, dammit!

Type coercion taken way too far ;)

Optical types are when they shave the bushy hair off of the type system, and it looks an inch longer.

https://www.youtube.com/watch?v=NsbXwzqlqsU

The types aren't optional. The types are always there. The type annotations are optional.

Reply on news.ycombinator.com