Reservations about TypeScript(daviesgeek.com)
daviesgeek.com
Reservations about TypeScript
https://daviesgeek.com/2017/08/reservations-about-typescript/
33 comments
Good point.
That being said, TS does suffer from something unique, in its JS interop. If my C program interfaces with a C library, I have great certainty that all of these were compiled at some point, and the types are sound (as much as C allows, at least).
In TS, if you're lucky a library you consume was written in TS, so you've got high certainty that the typings it comes with are really good. Less lucky: the developer wrote it in JS, but provides typings. Less lucky: a random person on Github reverse-engineered the typings and provided them on DefinitelyTyped. Less lucky: There are no typings available. You'll run into npm libraries in all of these categories.
That being said, TS does suffer from something unique, in its JS interop. If my C program interfaces with a C library, I have great certainty that all of these were compiled at some point, and the types are sound (as much as C allows, at least).
In TS, if you're lucky a library you consume was written in TS, so you've got high certainty that the typings it comes with are really good. Less lucky: the developer wrote it in JS, but provides typings. Less lucky: a random person on Github reverse-engineered the typings and provided them on DefinitelyTyped. Less lucky: There are no typings available. You'll run into npm libraries in all of these categories.
Even less lucky: coding in vanilla JavaScript. In the days before Definitely Typed, I still got a lot of mileage out of types in my code alone. It felt immensely more apt then using JSDoc to document types everywhere.
In my experience, even if you don't have types for a third-party library, you can get away with adding types for the interfaces you care about.
In my experience, even if you don't have types for a third-party library, you can get away with adding types for the interfaces you care about.
Good to know; if this were a stated reservation, that'd be worth writing about.
Additionally, there's Elm which compiles to JS and its most memorable claim to fame is that it's a JS framework where "runtime errors are always a compiler bug".
> Obviously you can find ways to break out of the type systems...
You can also accidentally have these issues if you are using incompatible pieces of software together. I was helping some colleagues with exactly this problem this week due to some changes in our toolchain.
EDIT: I wasn't clear. This was in a C++ codebase, but the same issue would have happened in C or any other compiles-to-assembly language.
You can also accidentally have these issues if you are using incompatible pieces of software together. I was helping some colleagues with exactly this problem this week due to some changes in our toolchain.
EDIT: I wasn't clear. This was in a C++ codebase, but the same issue would have happened in C or any other compiles-to-assembly language.
> Obviously you can find ways to break out of the type systems (void* cast?) but that's on you
Sometimes a type system can be proven to have no holes. (Of course, not counting the FFI, if any is provided.)
Sometimes a type system can be proven to have no holes. (Of course, not counting the FFI, if any is provided.)
Sometimes, but very rarely, if only because of FFI as you pointed out.
And usually there's something in the unsafe category that lets you break some rules, if only to give a pressure release as in the interop reply above.
I don't deny the existence of such a thing, just that there aren't many practical examples
And usually there's something in the unsafe category that lets you break some rules, if only to give a pressure release as in the interop reply above.
I don't deny the existence of such a thing, just that there aren't many practical examples
First point: "I found a bug but can't give an example."
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.
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.
Conclusion:
> 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 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.
Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data.
"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.
"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.
TypeScript is certainly not flawless and there are tradeoffs. But this is not a good argument against TypeScript. The point of TypeScript and any other statically typed programming language is to have type checking performed statically, that is before the code is actually translated into machine instructions and run.
Hello, at the end of the day it's all wildly swinging voltages imperfectly mapped to ones and zeroes. There are no types in any of this. It's all a huge number of abstractions stacked on top of each other.
The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.
The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.
That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system.
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?
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?
All fair points and totally valid.
My concern is the facade/promise of type security.
My concern is the facade/promise of type security.
Your quarrel is not with JavaScript (as everyone else has pointed out, there’s no reason one can’t build a secure compile-time type system on top of JavaScript), but with some of the specific design decisions made by TypeScript that open soundness holes, such as “programmers are too stupid to understand the difference between covariance and contravariance, so we’ll pretend everything is bivariant”.
See https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.
See https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.
This gives an explanation of why they made the choice: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-fun...
Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.
Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.
Forgive me if I misunderstand, I still don't understand your concern – TypeScript has type safety because it can check types at compile time (vs. JavaScript which has very limited type safety at run time). I don't think it's fair to call it a facade, because it is definitely commonly accepted as type safe.
> it's that TS compiles down to a language that has neither
What languages compile down to a language that has either? Most languages compile down to either machine code, or virtual machine code.
What languages compile down to a language that has either? Most languages compile down to either machine code, or virtual machine code.
> 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.
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) :-)
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?
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) :-)
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?
The answer is, not much. They're shockingly similar. Both are achieving very similar ends through slightly different means (the subtlety of `virtual` in C++ leading to vtables) -- dynamic dispatch of a function based on an instantiation (a collocation of a method, as you called it)
How you implement inheritance under the hood and how you interpret the `class` keyword is another false distinction the author makes.
How you implement inheritance under the hood and how you interpret the `class` keyword is another false distinction the author makes.
That is an appalling article, even by Hacker News standards.
I mean, his second "reservation" is that TypeScript "fundamentally" changes JavaScript. How does he demonstrate this? By complaining that classes, which are a JavaScript feature, work differently than in other OO languages. What the hell does that even have to do with TypeScript?
I mean, his second "reservation" is that TypeScript "fundamentally" changes JavaScript. How does he demonstrate this? By complaining that classes, which are a JavaScript 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.
Opinions are like buttholes, everone has one.
Opinions are like buttholes, everone has one.
I wish I had the actual code since it was pretty fun to write and break the compiler but it was too long ago. I am still gonna see if I can figure it out again.
I think I was pretty clear that it was all just my opinion :) If you read the end of the post I said that maybe I'm just worrying over something that's a non-issue, so by all means, steer me in the right direction rather than critiquing the fact that I'm expressing my opinions ;)
I think I was pretty clear that it was all just my opinion :) If you read the end of the post I said that maybe I'm just worrying over something that's a non-issue, so by all means, steer me in the right direction rather than critiquing the fact that I'm expressing my opinions ;)
I'd like to also point out that my main issue (that JS itself doesn't have types, so it's impossible for TS to 100% enforce it) still stands even after a year.
No, that point never made sense.
The fact that TS isn't sound has nothing to do with the fact it compiles to JS. If you wanted a sound type system, you should have checked out flow.
The fact that TS isn't sound has nothing to do with the fact it compiles to JS. If you wanted a sound type system, you should have checked out flow.
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.
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.
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.
An aside: check out BuckleScript's OCaml -> JS work. It's even better than Typescript's output.
Some examples:
https://github.com/BuckleScript/bucklescript-addons/tree/mas...
Some examples:
https://github.com/BuckleScript/bucklescript-addons/tree/mas...
It's gradual typing. Yes, it's full of holes, that's the whole point.
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.
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.
If you're curious about or skeptical of TypeScript, do yourself a favor and check out the source code sometime: https://github.com/microsoft/typescript
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: https://github.com/guscost/protozoa-tsx
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: https://github.com/guscost/protozoa-tsx
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.
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...
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