Second point: "It adds a feature that's different from a similar language."
These are not persuasive arguments. I'm not trying to be unkind, but the first point is totally unsupported and the second doesn't elaborate on what's bad about classes besides that another language also has classes.
> TypeScript brings some great features, but, in my opinion, it comes with some significant pitfalls that need to be addressed and realized before jumping in with both feet.
While listing none of the pitfalls unless the significant pitfall is classes mentioned a few paragraphs above.
This reads like it had much grander aspirations and ended up being published 30% through.
"TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.
The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.
Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't support anything like that.
Could you give a concrete example of a scenario in which the flexibility of the JavaScript type system would break the TypeScript type system?
My concern is the facade/promise of type security.
See https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.
Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.
What languages compile down to a language that has either? Most languages compile down to either machine code, or virtual machine code.