> Naively, someone might think you’d write fewer tests with TypeScript. That someone would be wrong.

Have you seen unit tests that check "what if I don't send the right number/type of arguments"? Yeah those unit tests are not necessary if you use TypeScript.

If you maintain a popular public project, you help the entire JavaScript community if you use TypeScript, because then you can ship perfectly accurate type definitions along with your code. Even if the user is using plain JavaScript, their editor can probably use those type definitions to provide coding assistance.

Also, it's hard to call something a "leaky abstraction" when it's a superset of the thing it sits atop.

I love TypeScript. It's like the good parts of Java (classes, type-checking, good support for service-based programming models) with Javascript goodness like handy functional programming tricks, concise code, reactive programming, and not having to worry about concurrency.

The biggest problem is that it lacks document that rolls up TypeScript and Javascript underpinnings in one place. As it is you can't just read the TypeScript docs at https://www.typescriptlang.org/docs/home.html and get started. Or rather you can but you'll promptly run into many cases where you can't reason effectively about behavior because you don't understand how Javascript works. (E.g., iterating over collections of Javascript entities.)

There have been a bunch of projects to create a better Java. TypeScript looks like one of the best attempts so far, in part because it broke free of trying to remain compatible at the VM level. It does not deal with every use case for that reason but looks like an excellent language for microservices. Interestingly the origin as a client-side language is not that different from how Java was first marketed...

Edit: Moved reactive programming to the javascript side of the fence (what was I thinking?)

> TypeScript doesn’t absolve you from learning JavaScript. When things go awry, you’ve still got to be able to spelunk the JavaScript code it produces.

TypeScript code is still 90% regular ES6 JavaScript, of course. That said I very rarely need to go grepping through the transpiled code.

The problem I have with TypeScript isn't the language itself, but the illusion of type safety that it gives you. It gives you a better developer experience at compile-time, there's no doubt there. My problem is once TS is transpiled, all type-related bets are off. You can easily find yourself in situations at runtime where a string is passed into to a function that's expecting a number. You may not get an actual runtime error, instead you might just see unexpected behavior. I've had to fix bugs due to this situation more times than I can count (I didn't write the original code) in our Angular app.

> Type-checking only helps with one class of bugs that can occur in a codebase

TypeScript is not only about eliminating bugs, for instance maintaining a large project is much easier comparing to Javascript.

However, A lot of teams would still use Javascript for small backend applications, and the best example is Lambda functions! With rising popularity of Serverless architecture JS is here to stay for backend.

While TS will remain a good alternative for many things of course.

I generally like Typescript, but I find it frustrating that it doesn't include a useful standard library. Instead, we're stuck with Javascript's bare bones of a library, which means a lot of thing that can be done in other languages just using their library, need to either code from scratch, or import from a 3rd party library.

The ugly: It is still javascript....

I heard this argument against CoffeeScript. At the time CS was still fucking amazing. And I loved it. Sure now people roll their eyes because JS has all the features coffeescript had, but not the indentation-based logic flow... Whatever. CoffeeScript 4 lyfe!

In any case, I see it as a positive. This is just like saying at the end you still gotta know Assembly to write in C...

Also they forgot to mention. Interfaces. Fuck I love interfaces. Self documenting code? Yes please. Awesome auto-completion from tools? Yes please. Sure if you develop in the caves like cavemen and use VIM only without anything to help you, sure, TS is slower. But the point is that amazing dev tools are amazing.

The problem with languages is when the type system isn't strong enough in some cases, but too strong in others. It would be nice for prototyping to use `var` and let the compiler figure the type out. However it would be awesome to write a method that says position 1 is a number between 1 and 100.

> TypeScript requires a build step. That might be enough reason for a JavaScript developer to say, “No, thank you.”

In my experience most JS developers have other considerations. Tests are also a build step, so good chance a codebase already has those.

Never got the answer: https://news.ycombinator.com/item?id=18978404