Hacker News new | ask | show | jobs
by elevader 1622 days ago
And it works in both directions. You can "easily" (I mean, this is JS afterall so this heavily depends on the degree of toolchain hell chosen) move to the TS toolchain and rename your files to have the .ts extension and you have a valid TS project and benefit from the inferred types for your code. Type annotations can then be added later on as you go. And the syntax everybody already knows stays valid. This is a huge benefit compared to something like ReScript because it makes adoption really easy. With the obvious downside of not having nice features like pattern matching.
2 comments

I agree that TS eases the transition from JS, but I'd qualify your statement by saying it's not the toolchain that's a source of headache.

Ideally, one should compile TS with `--strict`, otherwise there's little difference with JS. With this in mind, it's quick and easy to switch to TS tooling. Afterwards, one can incrementally adopt stricter typing, culminating in adding `--strict` to your `tsconfig`.

In reality, since `--strict` is false by default, I'm concerned people erroneously assume that their JS code is type-safe after the first step, when it really isn't. In other words, it's no different than JS, except in name only!

The problem with the add types later approach is that in the end you have half baked .ts files left and right. And it becomes increasingly difficult to know when something compiles if it's because it's correct or because there is an any somewhere.
Yeah, agreed. Ideally this wouldn't happen like that. Temporary solutions like a half-migration have a tendency to stick around for a lot longer than anybody anticipates. But I think it is still better than not having any types at all, if only for having type information in development.