> TypeScript compiles down to JavaScript, which doesn’t have types or type checking, it’s impossible to have actual type checking. The TypeScript compiler is great at checking at compile time, but at the end of the day, it’s impossible to actually check the types.<p>I'll point out that C/C++/Haskell compiles down to Assembly, which doesn't have types or type checking. GCC/LLVM/GHC is great at checking at compile time, but at the end of the day, it's all just bits being modified...<p>Obviously you can find ways to break out of the type systems (void* cast?) but that's on you, and even if Typescript has more escape holes, the existence of them isn't an immediate fail
First point: "I found a bug but can't give an example."<p>Second point: "It adds a feature that's different from a similar language."<p>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.
> <i>TypeScript fundamentally changes the way JavaScript works. JavaScript does not have classes. Even ES6 classes are just syntactic sugar on top of the ES5 prototypical inheritance. I’ll repeat it again. JavaScript does not have classes. The class keyword may exist in ES6+, but under the hood, it’s still just prototypical inheritance. As long as this is understood, it’s perfectly fine, but the problem comes when ES6+ or TypeScript is marketed as having “classes” in the traditional OOP sense of the word.</i><p>It looks like the author started out as saying one thing (how Typescript is fundamentally different from JS) and ended up with another (how they are fundamentally the same) :-)<p>Which reminds me. Could you please explain to me what are the proper classes? I guess I have spent too much time with JavaScript to start thinking about classes just as about collocations of methods and properties spewed out by constructors. What is so improper about JavaScript's prototype-based classes that is different in real classes?
That is an appalling article, even by Hacker News standards.<p>I mean, his second "reservation" is that TypeScript "fundamentally" changes JavaScript. How does he demonstrate this? By complaining that classes, which are a <i>JavaScript</i> feature, work differently than in other OO languages. What the hell does that even have to do with TypeScript?
Article lacks any actual, factual reservations, but rather complains about some code that didn't work a year ago and the code of course has been lost.
I don't get the point of sharing this writeup. I guess author just posted some text he wrote up for a internal company discussion.<p>Opinions are like buttholes, everone has one.
The authors main complaints seem to focus around "but Typescript isn't ES6". I don't have a problem with this because Typescript compiles down to very clean vanilla JS. Unlike C++ to C, Clojure, and Babel the compilation down to JS is extremely good in comparison.<p>Good enough that I usually debug the Javascript output. Typescript has the cleanest transpilation I've ever seen so I don't have any problems with using it. And if Typescript ever falls out of vogue I'm confident just compiling down to JS one last time and being done with it. Really the language is so easy to get rid of its harmless.
It's gradual typing. Yes, it's full of holes, that's the whole point.<p>There are other languages with strong, powerful type systems that compile to efficient JavaScript, such as (in order of power) Elm, OCaml, PureScript and Idris. Those four are just arbitrary examples however, there are quite a few more.
Sorry, I don't understand what this post is about, other than that you have some reservations about TypeScript. It's not really clear <i>what</i> those reservations are.
If you're curious about or skeptical of TypeScript, do yourself a favor and check out the source code sometime: <a href="https://github.com/microsoft/typescript" rel="nofollow">https://github.com/microsoft/typescript</a><p>It's a work of art, everything is so practical and (relatively) easy to understand. Even better, it's written in TypeScript, so you can open it up in an editor with TS support and follow/jump to any reference with confidence. I've only learned about compilers vaguely through osmosis, but I was able to extend its JSX syntax processing (admittedly that part does seem a bit bolted-on) to output JSON for my wonky framework side-project in a few hours: <a href="https://github.com/guscost/protozoa-tsx" rel="nofollow">https://github.com/guscost/protozoa-tsx</a>
Not to pry, but do you have a Java background? I see you're using the global 'Boolean' and 'String' interfaces in your examples (which correspond to the equivalent JavaScript constructor objects), rather than the 'boolean' and 'string' primitive types. While it kinda works to use the interfaces instead of the primitives, the primitives, IMO have much more expected behavior in the type system, since, unlike the interfaces, they do not get compared structurally - TypeScript uses a structural type system for all objects, after all.