Exactly my feelings about it. Being able to specify types, and having the compiler warn me of mistakes is a godsend when comparing it to just writing javascript.

And when valid javascript is valid typescript, it seems odd to not opt to use it when the only addition is a compile step to ensure sanity.

Same here -- I rewrote all my javascript code in Typescript and am very happy with the result.

No longer am I concerned about errant semi-colons or a stupid typo in a method name on an error handling path that a unit test missed.

There's js2coffee.org to copy paste JavaScript to CoffeeScript.

... just for it to be 'compiled' back to JavaScript...

Transparent integration with native Javascript is a huge advantage for Typescript over things like Dart, I think. The ability to gradually introduce typing into an existing codebase is going to make adoption so much easier.

That's exactly what I've found. We ported all of our JavaScript code to TypeScript because of this, and are on a hunt to remove 'any' types.

We found a bunch of real and potential bugs due to JavaScript's dynamic nature, particularly with regards to the number of function arguments (JavaScript being happy to ignore extra parameters or replace missing parameters with undefined).

    Saved a ton of time letting a compiler catch things instead of writing tests.

Types should never mean writing less tests :/

Static typing means automatic language-integrated type-checking unit tests. I would bet a lot of dynamic language unit testing has to do with compensating for the lack of proper type checking. It's just like using patterns compensates for lacking language features.

I don't like to think about type checking as unit tests because they approach the problem from a fundamentally different direction, and I worry conflating them could lead to writing the sort of bad unit tests people are talking about here.

Type checking, or static analysis in general, checks for the presence of a particular class of errors.

Unit tests check for correct behaviour, and in doing so imply a lack of any errors, types or otherwise.

While it can be good to use unit tests to check for regressions in a specific error, the core of your tests should be specifying the behaviour of your system, not trying to catch out any specific class of errors.

If your tests are busy looking for specific errors, there will always be some that you miss (type checking, even in Haskell, misses a lot of classes of error). If your tests check for correct behaviour, there can be no errors.

Of course, writing tests with perfect coverage and specifying all the behaviour is impossible, even more so when you've got actual features to get out the door. So any static analysis you're comfortable with can be great for making up some of the slack, but let's not pretend that in most cases we shouldn't now need to be writing those tests to check it does what it's meant to.

The place where this approach sometimes falls short is on the public API boundary, as I mentioned in my other post. Types can be useful there, so maybe my original assertion was a little too strong, but still types should very rarely mean less tests.

(Apologies if the post is a bit all over the place, redrafting on a phone is hard)

I understand your point, thanks.

Did not mean dynamic languages are bad. They are awesome for scripting on the static type language core. Unless you like writing _lots_ of basic unit tests.

i see people writing tests for the structure of returned objects

type annotation tests that at compile time

That suggests to me they're missing tests that check the data held in the objects.

There might be some worth in checking the structure of an object (including attached functions) as it leaves a public api, especially in a language like Javascript that plays it so fast and loose with object construction.

That's one of the nice thing about typescript - you can use it where it's most helpful and leave it where it's not.

he's right, you can cover more code using integration tests with a static typed language, unit test are then testing the functionality of individual classes.

especially for testing return types as C for example you assign those.

In C it's more popular to write example code which uses the library, and the errors are spotted at compile time.

Interesting. Is there a higher level lang that ONLY adds type safety and compile-time checking to JS?

Sounds like typescript v0.1 :) Seriously though, since all typescript features are optional, why do you want a language that doesn't have them at all?