CS also saves keystrokes and makes code more readable by offering things such as:

Reducing boilerplate for loop code:

    CS:
    for el, index in arr
      el.doThing(index)

    JS:
    for(var index=0; index < arr.length; index++) {
      var el = arr[index];
      el.doThing(index);
    }

Better iteration over objects:

    CS:
    for own k, v of obj
      console.log "#{k} is #{v}"

    JS:
    for(k in obj) {
      if(!obj.hasOwnProperty(k))
        continue;
      console.log(k + " is " + obj[k]);
    }

Default function params:

    CS:
    foobar = (foo = "default", bar = "shmefault") ->
        # Go on...

    JS:
    function foobar(foo,bar) {
        if(foo === null)
            foo = "default"
        if(bar === null)
            bar = "shmefault";
        // Go on... 
    }

String interpolation:

    CS:
    str = "There are #{num} #{item}s available for $#{price} each"

    JS:
    str = "There are " + num + " " + item  + "s available for $" + price +  " each";

Existential checks, soaking nulls:

    CS:
    if obj?.prop?.exists?
      console.log "obj.prop.exists"

    JS:
    if(typeof obj !== "undefined" && obj != null && obj.prop != null && obj.prop.exists != null)
      console.log("obj.prop.exists")

Yes, but that's just some syntactic sugar. That stuff doesn't help with tooling/scaling.

By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.

Language is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool.

CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling.

In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely.

If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.

> [JS generated from CS] runs faster [than JS generated from Dart]

There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good.

> it runs faster thus has its strength in scaling

"Scaling" as in: more developers, more files, more lines of code. Bigger projects.

CS doesn't help with that one bit. It's just as difficult to handle as JS. This is why Google came up with stuff like the Closure Compiler, GWT, and now Dart.

> Syntax is the only thing we can compare.

There are also semantics and the whole environment. Syntax is a small fairly unimportant detail.

> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS.

Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or other features from TS/Dart.

> AMDs like Require.js or CommonJS

That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general.

Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other.

I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issues. Naturally, it's also way more convenient to use. You just import something. Done.

> doesn't need static typing or other features from TS/Dart

You also don't need a seat belt or airbags. If you don't make any mistakes, you'll be fine.

However, from a pragmatic point of view, these static checks are very handy. If you rewrite some parts of your code, the analyzer will tell you if you screwed something obviously up. It catches all the stupid mistakes, which means you can fully focus on the logical ones.

With JavaScript/Python/etc you have to run the code and actually hit that particular branch to trigger some sort of error/exception which will eventually help you to identify the actual issue.

You should just give it a try. Try any language/IDE combination which offers good tooling. Tooling can remove a lot of friction. There really is a point to all of this.

Don't get me wrong, I agree that the overall experience is important - the best language in the world would be shit if you had to use notepad.exe to develop in it.

You like your IDEs and static typing and tooling, and it works for you (and for many others). I like my CoffeeScript, my AMD/CJS modules, and testing, and it works for me (and for many others).

Your experiences and assertions are wildly different than mine. I've never found AMD modules a problem. I have found overwrought and verbose code to be a problem. File headers? Interfaces? Java-style OOP in my JS? No thanks.

I think we're both just stating subjective opinions without substantiation, so I'm done here.

> File headers?

No.

> Interfaces?

Implicit interfaces. It's kinda handy.

> Java-style OOP in my JS?

I'm not sure what qualifies as "Java-style" OOP. Is the stuff from ES7 also "Java-style"? How about the stuff from CS?

Well, you don't have to use classes. You can do everything with functions if you want.

> I think we're both just stating subjective opinions [...]

The difference is that I actually tried it.

> heavy IDEs

If your machine has 6+ GB of RAM, it doesn't really matter if some IDE uses like half a gig of that. I mean, that's why you bought all that RAM in the first place, isn't it? The point was to use it, right?

Same deal with all those beefy cores. Giving one of them a little bit of work won't hurt one bit.

The only actual downside is that start up takes quite a bit longer than 100msec. However, if you're using it all day, it doesn't really matter if it took 15s to start, does it?

I believe that one should automate as much as possible. Offloading as much brain-dead repetitive work as possible to machines is always a good idea.

So, check if I use the right kind of arguments. Check if that thing has that field or method. Tell me if there are any methods which start with "foo" and if so, tell me their exact names, arguments, and return values. Tell me if the change I just did broke something.

That's the nice thing about machines. They will happily do this stuff over and over again, a thousand times a second. They'll never get tried of it. They'll never complain.

One thing I really dislike about JS is having to check documentation. If you want to use some library/plugin/whatever, you always have to go to its website, navigate to the docs, and then navigate to the specific section. Just to look up the arguments or the names/types of that config object you have to pass to that function.

It's so much nicer and also way faster to do that kind of thing directly in the IDE.

> enjoy TS

I use Dart. And yes, I do enjoy it. It's very pleasant to use.

You "scaling" is just a syntactic sugar to the underlying package/module solution. In js/coffee the syntax just don't care about it, and you use package/module with a library.

Most of the semantics or environment stuff are translated into function calls at last. Then the difference becomes the syntax again: how to use that function? Call it directly or translate a syntax?

I like coffee because it is practical scripting: Need code completion? Don't repeat yourself. Can't code without IDE? Make the language easier to use then you ain't gonna need it. Some people just can't believe a language can be that good without IDE, but remember: you interact with IDE through a language on keyboard/mouse too.

It's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes.

That's awesome that Dart includes those features, and I wish that I had lexical scoping in CS. But closures are a pretty easy workaround.

> TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.

That sounds like an IDE/editor feature, not a language feature. Setting up macros/snippets/etc in an IDE/editor will save keystrokes for most any language.

> That sounds like an IDE/editor feature, not a language feature.

Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.

By "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit <tab> and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate).

CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I like JS, and I like that it doesn't try to shoehorn in concepts foreign to JS.

It's possible to build scalable systems in JS/CS without what TS/Dart offers. You might not be able to do so from your experience, but that doesn't mean it's not possible.

That would be "snippet expansion" (pioneered in TextMate, if I'm not mistaken — well, that's where I saw it first).

"Autocompletion" is… "automatic": you type the beginning of a method name and you get a contextual menu following your cursor showing a list of suggestions. Many editors have that feature, either built-in or via plugins, but it's definitely an area where IDEs shine. If the editor/IDE has a way to infer scope, you get good completion, if not, you get mediocre completion.

But "snippet expansion" or "templates" as they are called in some IDEs is very easy and doesn't require statical analysis or whatever.

> By "autocomplete" you mean [...]

All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method.

If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete "bar").

It's similar to writing C#, AS3, or Java with a good IDE. If you have never experience any of that, maybe you should give it a try.

> It's possible to build scalable systems in JS/CS without what TS/Dart offers.

Sure. It just requires more time and money.

You can, for example, also chop down a tree by using an axe instead of a chainsaw. There is always a more difficult more time consuming way to do something.

Right, but that's about a certain IDE not the language itself, regardless of whether it's TS or JS. Sublime text does that for any JS file, as does Vim with the right plugin. I bet whatever IDE you're using will do that with bare JS. It's not "guessing" with JS completion any more than it is with TS. Again, autocompletion has nothing to do with the language.

> Sure. It just requires more time and money.

Care to back that up? I'll wait over here. Oh, unless you meant that it would take more time and money for you. Then sure, I agree.

> that's about a certain IDE not the language itself

This stuff is only possible if you can analyze the code statically.

With JS, which is running in a browser, you don't know anything. You don't know what other kinds of scripts are running on that page. You don't know which globals these introduce or which built-ins they modify.

E.g.:

    Math.round(5).length

You don't know if Number has a length property. You don't know if "round" takes a Number as argument. You don't know what this "round" function returns. You don't know if the "round" function exists. You don't know if a "Math" global exists.

For tools, this is a big problem.

In Dart, the analyzer knows about all these things. If the function is annotated, I'll get all the tooling and checks.

> Care to back that up?

No. You can't even imagine what good tooling is like. Naturally, you're blind to the friction which is caused by a lack of good tooling.

For kicks, here's Dart versions of those:

Reducing boilerplate for loop code:

    var index = 0;
    for (var el in arr) {
      el.doThing(index++);
    }

Dart hasn't really optimizing for iterating over a collection with indices since we don't find that very common in real-world code.

Better iteration over objects:

    obj.forEach((k, v) => print("$k is $v"));

Here, obj is a map data structure, not a random object since Dart distinguishes objects and data structures.

Default function params:

    foobar([foo = "default", bar = "shmefault") {
      // Go on...
    }

String interpolation:

    str = "There are $num ${item}s available for \$$price each"

Does Dart compile that for loop down to a regular for loop instead of the JS for..in loop? Or are there any safeguards against someone adding a property to an array (not that they should)?

    a = [1,2,3];
    a.prop = "oops";
    for(el in a)
      console.log(el);
    // > 0
    // > 1
    // > 2
    // > oops