
Reservations about TypeScript - daviesgeek
https://daviesgeek.com/2017/08/reservations-about-typescript/
======
barakm
> 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.

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

~~~
013a
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.

~~~
fny
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.

------
Harkins
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.

~~~
daviesgeek
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.

~~~
nkohari
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?

~~~
daviesgeek
All fair points and totally valid.

My concern is the facade/promise of type security.

~~~
anderskaseorg
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...](https://www.typescriptlang.org/docs/handbook/type-
compatibility.html) for a less cynical presentation of these design decisions.

~~~
nkohari
This gives an explanation of why they made the choice:
[https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-
fun...](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-function-
parameters-bivariant)

Also, FWIW, in my experience, I don't think I've ever actually run into a
problem with this in real code.

------
azangru
> _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?

~~~
barakm
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.

------
stupidcar
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?

------
kxkciicoiciic
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.

~~~
daviesgeek
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.

~~~
winstonewert
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.

------
forgotpw1123
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.

~~~
ctvo
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...](https://github.com/BuckleScript/bucklescript-
addons/tree/master/examples)

------
mixedCase
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.

------
nkohari
Sorry, I don't understand what this post is about, other than that you have
some reservations about TypeScript. It's not really clear _what_ those
reservations are.

~~~
phaed
He started with the conclusion, then went and tried to look for reasons to
support it. Problem is he came up short.

------
guscost
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](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](https://github.com/guscost/protozoa-
tsx)

------
wwwigham
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.

