
Ask HN: Is TypeScript really that productive? - prmph
Been using TypeScript for a while now. While the concept is excellent, the implementation in various IDEs and release process seems very much to work against really getting work done.<p>On my machine, the tsc compiler seems to use a different version from the one in VS Code, because I see highlighted errors in the editor that do no show up when I actually compile, and vice versa.  I cant even find an easy way to know the version of TS that the VS Code editor is using.<p>Also, there seems to be a thousand different  ways to reference and&#x2F;or import other modules, and they vary with each version, such that I&#x27;m never sure. Implicit referencing sometimes works, sometimes does not.<p>Why Typescript can only compile .ts files is beyond me.<p>As usual, Microsoft is long on ideas, and short on execution. Until they fix the tooling issues, I think I will just say no.
======
jmlee2k
\- You can see which version of typescript is being used in VS Code in the
bottom-right corner while a typescript file is open.

\- 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.

~~~
prmph
> You can see which version of typescript is being used in VS Code in the
> bottom-right corner while a typescript file is open.

No, you can't, and I have the latest version of VS Code (I can link to a
screenshot if needed). This illustrates the confusion around the tooling. Many
TypeScript answers on SO do not even work with the latest versions of the
tools

~~~
jmlee2k
That's very odd. I'm quite new to VS Code, so this could be confusion on my
part. I am running on the latest TS (typescript@beta and typescript@next
before that), so perhaps that's why I see the version number.

------
mattmazzola
There seem to be two different questions in your post.

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.

