Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I just can't justify writing my team's code base in typescript. I don't want to make that move, setting us down a very specific path. I don't want to add another layer of training to develop on our codebase, but mainly, I just don't have the confidence that it's a right or wrong choice, and its a big choice.

But I get a sense that it would be great to try for smaller, disposable projects as that's limited risk.

Does anyone else struggle with TypeScript simply because of how big a choice it can be?

View on HN

My impression of TypeScript, is that the .js it produces is actually extremely legible. This is especially true if you mainly use it for strict typing.

So in theory you could give it a go, and if you decide you don't like it after a while, you could continue development on your .js files and ditch the .ts files.

Chances are that you'll love TypeScript though.

It also depends on how deep do you want to go with language features.

Let's say you have existing ES2015 source code. You could start experimenting on a local machine and use a script to rename js files to ts. Run the TypeScript compiler and annotate some of the most used functions.

You can then check what is the experience of using those functions that have type annotations, what is the speed of the development, etc.

Sit down with colleagues, show what you have done and ask what do they think. You can then decide to proceed and stick with type annotations until you're sure. Use boy scouts rule: "Always leave the campground cleaner than you found it." aka add typings to the function declaration.

The advantage of TypeScript is it emits idiomatic js. Decided that optional static typing is more trouble than it's worth? Fine. Bin your ts and keep the js. The code is totally fine. This is the attitude our team adopted when we first tried it out back in the 0.9 days. We didn't go back. You won't want to either

What "level of training" are you talking about? TypeScript is a JavaScript with opt-in types. Rename .js to .ts - it's a valid TypeScript file. You can gradually enrich the code base with type information, while still keeping old stuff intact.

One of the huge benefits is that you can start using "future" features (like sane variable scoping, for example) of JS now - TS will treat the code as "new", but downcompile it to what current browsers can understand.

You could start incrementally with Tx3's suggestion -

> One thing I would like to add regarding the .js files, TypeScript 1.8 added a flag --allowJs which makes some sanity checks to the plain old .js files.

Or burai's suggestion -

> Another good alternative is Facebook's flow. Rather than being a transpired language it works on top of JavaScript files.

I wrote in a previous post that I enjoy working with Typescript and overall it's a win for our team, but these days I sometimes wonder how much of a win over es6/7.

I've found the biggest headache is getting all the *.d.ts files setup right and setting up your own types can sometimes be a pain, but as I mentioned it's pretty opt-in.

You don't use TS because of the ES6 features. If that's your goal then you can simply stick with babel. You use TS because of the type checker, and that will not be part of ES6/7.

ES6/7 doesn't have static type checking.

Reply on news.ycombinator.com