Ask HN: Is TypeScript really that productive?

1: Is TypeScript really that productive? Yes, absolutely. Intellisense, Go to definition, and compile time errors greatly increase productivity.

My opinion is that if you're working on a brand new project that has small code base you probably won't see much benefit from TypeScript. You would already know every function signature and connection between logical layers because you wrote all the code and it's small enough to keep all this in your head. However, if you start working on larger projects or get handed a new library / framework and you need to quickly ramp up on how to use it, the features I listed above basically mean the code is self-documenting (you no longer have to go to the API/docs website because the code is fully typed) and this forces you to learn how to use the new code correctly and with a short feedback loop because there are compile time errors.

2. Does TypeScript currently have a higher barrier to entry? Yes, absolutely. Although it's getting significantly better with every release and the next version which allows customizing module resolution and more flexibility for location type definitions through npm will help this significantly.

More detail on your other points: "tsc compiler seems to use a different version from the one in VS Code" VS Code should be using the local version installed in your project or the one located globally.

"I cant even find an easy way to know the version of TS that the VS Code editor is using" You should be able to see the version by typing `tsc -v`

"I see highlighted errors in the editor that do no show up when I actually compile" There's not enough information to know how you're compiling the code outside of VS Code, so I can't say for sure, but it would be recommended to setup a tsconfig.json file in your project (which is just json representation of the command line options you can pass to tsc) and then a basic setup would use `tsc -p .` to compile using this configuration in the current directory.

You can always extend with gulp webpack ect..

"Why Typescript can only compile .ts files is beyond me." I believe there is a newer "allowJs" option that does support something like this. I believe it uses JSDoc comments as substitutes for types and allows you all the benefits of TypeScript for libraries without .d.ts files if they have thorough JSDoc comments, but I haven't experimented with this myself.

In most cases you can just declare a module as "any".

"there seems to be a thousand different ways to reference and/or import other modules" I would agree this has been a problem. For me the confusing came from typescript having introduced 'module' keyword before es6 modules were standardized. Avoid using 'module' keyword and use ES6 style modules. If you really must you can use namespaces but there are often better ways to restructure files for same effect.

Also, avoid using /// <reference path="path/to/lib/index.d.ts" /> and use typings tool instead.

Lastly, there are some libraries which don't have correct type information and have to be imported like this:

import foo = require('foo');

which is a combination of es6 and commonjs formats, this caused me much confusiong as well, but from my understanding it's a necessary workaround to allow people to use those libraries TypeScript. IMO, avoid this syntax whenever possible.

"Until they fix the tooling issues, I think I will just say no" You're not alone with this opinion, TypeScripot definitly has more things to learn to get it setup and it's own set of frustrations, but at least you can know they are working on it and hopefully if you look back in few months the ecosystem will be ready for you.

- It does take a lot of time to get a TS environment setup, but I have to agree with the previous commenter, the benefits are completely worth it. This is just my opinion of course, but it's allowed me to finally treat JS as a development option.