
Good reasons not to use TypeScript - gymshoes
https://medium.com/javascript-in-plain-english/7-really-good-reasons-not-to-use-typescript-166af597c466
======
gymshoes
This article looked like a deliberate sarcasm or the author's points were very
weak.

------
mcv
We switched our project to Typescript about a year ago, because we had to
handle a lot of different types of data, and it was nice to know which type
you have in your hands. I wrote a bunch of code to parse anonymous JSON
objects and turn them into objects of the proper types. We added interfaces
for all sorts of things.

End result: checks don't work, because all our data is run-time. Most of our
parameters are still of type `any`. We need to explicitly specify types
everywhere that are either `any`, or they're not actually checked. I
discovered recently that someone had accidentally created a type that was
conceptually the duplicate of an existing type. One of those should never ever
get used, but the code doesn't complain, because it's only encountering this
in runtime.

So I'm inclined to agree: Typescript doesn't really add what it's supposed to
add. It adds a lot of work, without providing the security we expect from it.

~~~
Waterluvian
I think you used the wrong tool or misunderstood how to utilize typescript. If
you want guarantees of data integrity from external sources, try something
like Json Schema.

Or even without that, your data should be entering the system as type
'unknown'. There's then a validator function that takes in unknown and outputs
the intended type.

From there onwards, integrity is guaranteed by typescript, but only if you
have the discipline to use it consistently. Otherwise, yeah, don't bother.

~~~
mcv
The second one is what I did: I've got a function that I can throw any of my
anonymous data objects into, and it turns it into a typed object that knows
its type and has the relevant class methods. And this worked fine with
Typescript as long as nobody accidentally introduced a wrong class. Or
actually it kept working fine after that, because the system simply ignored
the types during runtime, so nobody noticed there was one bad class in the
mix.

Anyway, we're going back to simple JSON objects. Typescript is clearly not
helping in our case, and the whole process with parsing all incoming objects
is fairly cumbersome without adding much value.

~~~
javcasas
I work with Haskell, a language that some people call "pinnacle of type
systems". Guess what would happen if I use `unsafeCoerce`? Exactly the same
that would happen if I use `<any>` in Typescript. All the type guarantees go
out of the window.

In your code, if someone throws a bad class into the mix, it will blow up both
in Typescript and in Java/C# and in any other programming language. But,
somehow, blowing up in Typescript is way worse that blowing up in Java/C#. Go
and tell me that when I'm not allowed to put `nulls` anywhere neither in Java
nor in C#, because that's something I can do in Typescript today.

~~~
mcv
Being able to ban null values is absolutely fantastic. That's definitely a big
improvement over Java, and seeing it in Typescript makes me wonder why Java
allows it. In fact, seeing Option in Scala made me wonder why anyone ever
thought null was a good idea.

Even if it's only a compile time check, and can therefore still be
circumvented at runtime, this check for null values has still helped me out a
lot. At least within a class it ensures my assumptions are consistent, which
is not nothing.

------
wruza
I don’t see how having at least some types is more risky than not having them
at all. Type system is an instrument that prevents you from e.g. using/setting
x.id instead of x.y.id silently and succesfully (for some time). The entire
argument is stretched on the particular situation of a malformed input.

I think it is well-known fact among programmers that a prototyping phase of
10kloc+ project _requires_ types. Not for a formal proof, but to help
programmers to understand their code better and faster at monday morning
through a type error feedback. There is no reason to not use ts the same way
there is no reason to not have a ruler and yesterday’s sketches in your
toolbox.

Everyone may have their opinion, but this modern “media presence in software
development” nonsense goes beyond all limits.

------
chiyc
Watching the talk "Typing the Untyped: Soundness in Gradual Type Systems" by
Ben Weissmann
([https://www.youtube.com/watch?v=uJHD2xyv7xo](https://www.youtube.com/watch?v=uJHD2xyv7xo))
gave me an appreciation for the challenges in designing in a gradual type
system like TypeScript.

When I first started using TypeScript, I was surprised to find that it
wouldn't compile code I absolutely knew was correct, or that it would allow
"risky" code in some cases as the author says. The talk formalized the issues
I faced using TypeScript by teaching me about soundness, completeness, and the
trade-offs that are often taken between the two.

Generally, TypeScript has made my life a lot easier than the occasional
trouble it's brought me.

------
coffexx
We have a few TypeScript projects where I work at, one of them in particular
had to ingest data from a large number of our internal APIs and do some
crunching with it.

Validation of this data was essential, the crunching was complicated, and we
wanted to be able to make assumptions about the data through the type system
to make the code simpler.

We found JSONSchema validation was a perfect fit for this purpose (via ajv).
In all the overhead of maintaining JSONSchema files was much lower than we
thought it would be, and it even exposed some bugs in our internal APIs that
we patched up at the same time.

I do wish there was a nice way to generate that sort of validation code
directly from a TypeScript interface though.

------
joppy
I think the point about arbitrary data entering your system once everything is
compiled is quite valid: it is common to call into typescript-compiled code
from arbitrary JavaScript. Typed Racket had an interesting solution to this,
where it would generate run-time contract checks at all of the typed-to-
untyped boundaries, and so it could be sure that a compiled typed function was
indeed receiving objects of the correct form.

------
pjmlp
A very good point that experience has taught me:

It is not a platform language. Thus just like any guest language brings its
own tooling, idiomatic library wrappers around platform libraries, an
additional code generation layer to debug, having to write FFI (or type
declarations to platform libs).

Having said this, I do use TypeScript in the context of Angular or BabylonJS,
but that is because those frameworks are the "platform".

~~~
seanmcdirmid
Typescript doesn’t really do code generation, it transpiles via pure type
erasure unless you are targeting an older JS runtime.

~~~
pjmlp
Which is what almost everyone does, because we don't control what browser
customers use.

~~~
seanmcdirmid
Yes, sort of. I don't bother with it since I just develop demos.

Anyways, it doesn't really matter that much given source line annotations. I
wish TypeScript went with some more aggressive sugar so we could have nice
things like operator overloading.

------
winrid
Client side I love TypeScript, especially in Angular.

Server side? Gimme Java, most of the time.

