[estavaro]

The problem is that it makes people more concerned about getting the types right than about giving people shortcuts.

The API designers end up creating a multitude of APIs to deal with different type parameters and so on, to get their "generics" right and so on.

It makes the APIs look like Java APIs more than they jQuery ones.

Part of the problem is that the designers really want to get the types of classes and so on right on their parameters and return types. The types go beyond the primitives.

I've been able to watch it unfold and it's rather painful. The result looks less like a scripting language API and more like a C# collection of libraries, for better or for worse.

[ahoge]

> giving people shortcuts

I don't see any problem there. The code is very compact. There are lambda expressions, method cascades, and user defined operators.

Also, structure is baked in. You don't need any of that AMD boilerplate code. Annotations are also baked in. You don't need to write those lengthy doc comments.

Additionally, you can auto-complete everything.

> It makes the APIs look like Java APIs more than they jQuery ones.

With jQuery, you often have those "options" objects which force you to check the documentation even if your editor is somewhat jQuery aware.

With Dart, you can just use named arguments. It's also clearer what the default values are. Of course things are also a lot easier if the machine can tell what you're trying to do.

> more like a C# collection of libraries

Well, that's the whole point. If you put type annotations at the API boundaries, those annotations can be used for documentation (fully cross-referenced), call-tips, auto-completion, type inference, and basic sanity checks.

This gets rid of lots of friction. Even if your own code doesn't include any types, the editor will be able to tell what's going on in many cases.

E.g. it knows that `1 / 3` results in a `double`, which has a `toStringAsFixed` method, which returns a `String`, which has a `length` getter, which returns an `int`.

So, if you accidentally write "lenght", the editor will tell you about your mistake right away. Well, you won't even make that typo in first place, because you'll just auto-complete that word.

Furthermore, if you store the value of `length` in a `var`, the editor will remember that it's actually an `int` and it will then notify you whenever you're doing something weird with it.

All of that works just because the libraries you're using are annotated.

[estavaro]

The help of an IDE restricts the use of the language. It's the same for the TypeScript variant. If you say "you need a Visual Studio" or the like to use it comfortably, you're restricting the use-cases of the language.

I forgot to give the example of using "Enum-like" types instead of boolean parameters, because boolean parameters don't give enough information, so then you might need to pass something like MyClass.MYVALUE to a parameter rather than true or false.

So yes, there's much to like and dislike. Needless to say, there are those that need more type features from the language and toolset than it already offers, even if it's kind of hard because to come up with more if some of it needs to go into compiling down to JavaScript.

With more type features they would expect to have more features like real Enums or what-have-you.

Even "var" declaration starts to look awkward in a language where types are available. So things like "for (int i = 0; i < 10; i++) {}" are more natural than "for (var i = 0; i < 10; i++)". And that's only the tip of the iceberg.

When you start declaring things like "listenToMouseEvent(MouseEvent e, () {})" when using some event API, that's when it gets uglier still.

But yes, to each his own. JavaScript is still the leader in many ways, including some basic performance despite not the extra type declarations. They have really extracted nearly all of the performance allowed from JavaScript it seems. So performance alone is not what will differentiate these other languages from JavaScript.