
If It Ain't TypeScript It Ain't Sexy - aaronpk
https://developer.okta.com/blog/2019/02/11/if-it-aint-typescript
======
mohsen1
> Naively, someone might think you’d write fewer tests with TypeScript. That
> someone would be wrong.

Have you seen unit tests that check "what if I don't send the right
number/type of arguments"? Yeah those unit tests are not necessary if you use
TypeScript.

~~~
shados
They're not necessary in JS either.

You'd presumably have at least some tests in the form of "Give these input,
get that output". By checking that output, you pretty much confirm its the
right type at the same time.

I've seen a lot of test suites that have stuff like:

"given input A, test that result is defined. Given input A again, test that
result is 1234". It's like, yo, if result is 1234, its obviously defined.

There are edge cases, so yeah, the amount of tests you don't write in TS is >
0, but it's far and few in between.

~~~
nicoburns
It was pretty common to write runtime type assertions at the top of functions
in JS before TS was invented...

~~~
shados
Different topic than unit tests, but also if its in the public interface of
your code and you don't control all callers, you might need those assertions
anyway (since they could be invoked from non-TS code, or they could have been
cast to a any type, especially in non-strict mode TS)

------
poink
If you maintain a popular public project, you help the entire JavaScript
community if you use TypeScript, because then you can ship perfectly accurate
type definitions along with your code. Even if the user is using plain
JavaScript, their editor can probably use those type definitions to provide
coding assistance.

Also, it's hard to call something a "leaky abstraction" when it's a superset
of the thing it sits atop.

~~~
reverentgeek
True, it's not the same kind of leaky abstraction you find with other
technologies. I'm thinking more about the newcomer to JavaScript/TypeScript,
who has only focused on the latest language features, trying to get a grasp of
what is going on in the ES5-compatible code that gets generated.

Same is true with relying on Babel, of course.

~~~
WorldMaker
More so than any random Babel preset someone might hand a new developer,
though, Typescript has been pretty strict at this point towards staying
strictly to ES Stage 3+ proposals. (And the few exceptions [enums, namespaces]
are all common JS patterns that just about anyone should recognize the
generated code, and are easy enough to avoid if you want to be more strictly
ES Twenty Xteen+Types.)

(Also, the current Babel wisdom of "last two browser versions" suggests that
ES2015 or ES2016 is the compatible downlevel of choice in 2019, rather than
ES5.)

------
hodgesrm
I love TypeScript. It's like the good parts of Java (classes, type-checking,
good support for service-based programming models) with Javascript goodness
like handy functional programming tricks, concise code, reactive programming,
and not having to worry about concurrency.

The biggest problem is that it lacks document that rolls up TypeScript _and_
Javascript underpinnings in one place. As it is you can't just read the
TypeScript docs at
[https://www.typescriptlang.org/docs/home.html](https://www.typescriptlang.org/docs/home.html)
and get started. Or rather you can but you'll promptly run into many cases
where you can't reason effectively about behavior because you don't understand
how Javascript works. (E.g., iterating over collections of Javascript
entities.)

There have been a bunch of projects to create a better Java. TypeScript looks
like one of the best attempts so far, in part because it broke free of trying
to remain compatible at the VM level. It does not deal with every use case for
that reason but looks like an excellent language for microservices.
Interestingly the origin as a client-side language is not that different from
how Java was first marketed...

Edit: Moved reactive programming to the javascript side of the fence (what was
I thinking?)

~~~
rickette
> I love TypeScript. It's like the good parts of Java (classes, type-checking,
> good support for service-based programming models) with Javascript goodness
> like handy functional programming tricks, concise code, reactive
> programming, and not having to worry about concurrency.

This, 100%. And I'm saying that as a guy who's been writing Java for the
better part of 10 years.

------
ng12
> TypeScript doesn’t absolve you from learning JavaScript. When things go
> awry, you’ve still got to be able to spelunk the JavaScript code it
> produces.

TypeScript code is still 90% regular ES6 JavaScript, of course. That said I
very rarely need to go grepping through the transpiled code.

~~~
marcosdumay
Do you debug TypeScript code? If I get the code on the browser to place a
breakpoint, it's JavaScript there, is there some way to transpile it so it
carries the extra information?

~~~
bdcravens
That's what source maps are for (same situation as if you use ES6 and/or a
framework and end up transpiling via Webpack etc)

~~~
shados
sourcemaps are buggy as hell though (browser's devtools, and just generally
the specification's problem, not TS's), and a lot of devtool features don't
work with them. Debugging non-trivial problems with sourcemaps on is
infuriating. It's really rare (though it happens every now and then in complex
software) to have to go down to bytecode or native in something like C#, but
in JS/TS/whatever, it happens all the time.

------
GiorgioG
The problem I have with TypeScript isn't the language itself, but the illusion
of type safety that it gives you. It gives you a better developer experience
at compile-time, there's no doubt there. My problem is once TS is transpiled,
all type-related bets are off. You can easily find yourself in situations at
runtime where a string is passed into to a function that's expecting a number.
You may not get an actual runtime error, instead you might just see unexpected
behavior. I've had to fix bugs due to this situation more times than I can
count (I didn't write the original code) in our Angular app.

~~~
wvenable
That's the problem with JavaScript, not TypeScript. TypeScript doesn't
eliminate that problem but it doesn't cause it either.

TypeScript does heavily mitigate that problem by verifying all the types that
it can at compile time.

------
stunt
> Type-checking only helps with one class of bugs that can occur in a codebase

TypeScript is not only about eliminating bugs, for instance maintaining a
large project is much easier comparing to Javascript.

However, A lot of teams would still use Javascript for small backend
applications, and the best example is Lambda functions! With rising popularity
of Serverless architecture JS is here to stay for backend.

While TS will remain a good alternative for many things of course.

~~~
lstamour
You’d be surprised the number of places you can use TypeScript where only JS
is supported. Most recently, TypeScript allowed me to easily use modules and
ES2018 syntax with the legacy, somewhat terrible Google Apps Script JS engine,
thanks to Clasp:
[https://github.com/google/clasp/blob/master/docs/typescript....](https://github.com/google/clasp/blob/master/docs/typescript.md)

I often find merely searching for a typescript-compatible solution helps me
discover some of the safest and bug-free options quickly, avoiding legacy
jQuery-era projects.

------
mcphage
I generally like Typescript, but I find it frustrating that it doesn't include
a useful standard library. Instead, we're stuck with Javascript's bare bones
of a library, which means a lot of thing that can be done in other languages
just using their library, need to either code from scratch, or import from a
3rd party library.

~~~
lstamour
Don’t overlook the number of options available out of the box with the —lib
parameter: [https://www.typescriptlang.org/docs/handbook/compiler-
option...](https://www.typescriptlang.org/docs/handbook/compiler-options.html)

In many ways, I prefer this approach—it means TypeScript as a language will
stay compatible with JavaScript, and keeps options like Babel 7’s outright
removal of TS types easily done. If you need a feature JS doesn’t have, import
it, or pick a browser or runtime API. Seems simple enough to me. :)

~~~
mcphage
> Don’t overlook the number of options available out of the box with the —lib
> parameter

Thanks! I honestly wasn't aware of that at all!

> it means TypeScript as a language will stay compatible with JavaScript

If Typescript's library was written in JS, then the elements that were needed
can be compiled down and included with your code.

> If you need a feature JS doesn’t have, import it, or pick a browser or
> runtime API

I really appreciate standardization—that way everyone is on the same page with
basic methods. I don't have to worry about learning multiple versions, or
worry that code I'm reading is doing the same thing in a slightly incompatible
way. Or listen to people arguing about those same minor differences :-)

------
Justsignedup
The ugly: It is still javascript....

I heard this argument against CoffeeScript. At the time CS was still fucking
amazing. And I loved it. Sure now people roll their eyes because JS has all
the features coffeescript had, but not the indentation-based logic flow...
Whatever. CoffeeScript 4 lyfe!

In any case, I see it as a positive. This is just like saying at the end you
still gotta know Assembly to write in C...

Also they forgot to mention. Interfaces. Fuck I love interfaces. Self
documenting code? Yes please. Awesome auto-completion from tools? Yes please.
Sure if you develop in the caves like cavemen and use VIM only without
anything to help you, sure, TS is slower. But the point is that amazing dev
tools are amazing.

The problem with languages is when the type system isn't strong enough in some
cases, but too strong in others. It would be nice for prototyping to use `var`
and let the compiler figure the type out. However it would be awesome to write
a method that says position 1 is a number between 1 and 100.

~~~
saghm
> The problem with languages is when the type system isn't strong enough in
> some cases, but too strong in others. It would be nice for prototyping to
> use `var` and let the compiler figure the type out. However it would be
> awesome to write a method that says position 1 is a number between 1 and
> 100.

Out of curiosity, which of those two cases do you think of as having too
strong a type system? To me, both of them (type inference and numeric bounds
at the type level) seem like they require a stronger type system to fix, not a
weaker one.

------
sebazzz
> TypeScript requires a build step. That might be enough reason for a
> JavaScript developer to say, “No, thank you.”

In my experience most JS developers have other considerations. Tests are also
a build step, so good chance a codebase already has those.

------
madmaniak
Never got the answer:
[https://news.ycombinator.com/item?id=18978404](https://news.ycombinator.com/item?id=18978404)

~~~
seattle_spring
All of Airbnb? All of Facebook (in Flow)? All of Palantir, Coinbase, and
Stripe?

No one answered that post because your history proves that you are not asking
in good faith.

~~~
madmaniak
Interesting claim about Airbnb or Facebook. Thanks for an answer didn't knew
it and I was seriously interested. I always ask to get answers - in good faith
for me and others. No idea why you stalk my history and make false
assumptions.

~~~
seattle_spring
Haha Jesus. I originally saw this post because you linked to it from another
crazy uninformed rant on ts, not because I "stalked your profile." Get a grip.

