6 comments

[ 2.9 ms ] story [ 28.6 ms ] thread
Having read the post, I wonder about debugging of typescript, especially in the browser environment. Source maps work to some degree, but do those scale for a large project? What is the experience of debugging a large application built using TypeScript compared to plain Javascript?
With typescript typing you generally should need less debugging.
I'm using Babel ES2015 source maps in small-mid projects and usually their accuracy is acceptable though sometimes you'll meet weird lines (which need several 'step-over's before you finally step over them).

... or do you mean whether we get huge performance issues with the Typescript source maps while debugging large scale projects or not?

TypeScript's generated code looks very much like how you would write it if you did it in ES5. Classes are prototype based, namespaces are variable with IFFEs, modules are commonjs or requirejs, etc. This means that the generated code feels like your own code, variables, parameters and function names are the same so it's actually your code in ES5. Because of all these reasons we never felt the need to use source-maps (TypeScript can generate them). The only source-maps that we did use was for the minified files.
Gil, which environment do your teammates and you prefer for the TypeScript development?

How do you think: does Microsoft Visual Studio (as a TypeScript's _vendor_ development tool) have any serious advantage over the other IDEs and editors in a sense of an autocompletion and compile-time errors support?

When TypeScript was first released yea, VS did offer all the power of TypeScript, but these days the compiler is soo easy to plug into that you have integration for any big IDE out there, and they are all very good at bringing the power of auto-complete, refactoring, intellisense, stc. It is not all perfect, and there are still issues that each IDE suffer from, but it's much much better than plan JavaScript where it's all "guesstimate"