> It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time);

Have you ever used `tsc --watch`? First build can take long but modification and rebuild takes < 1s.

> you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.

You don't "have to" use the debugger if you prefer `console.log` all the way. However in the debugger there is a "watch" tab for inspecting specific variables.

> Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.

VSCode? https://code.visualstudio.com/

Using console.log is not practical with TS because I only get one chance per debug cycle to log the value of the variable which I think is of interest. If that doesn't give me any insight, I have to log another variable. This is fine with JavaScript because it takes me about 2 seconds to add a console.log and check it. With TypeScript, the cycle takes about 10 to 15 seconds, so it's not efficient to do that, so yes, I end up having to fiddle with the debugger, add watchers and hover over individual variables... I kind of have to deal with the debugger's clunky UI every time which is slower. If source maps don't work correctly (as was the case for a lot of projects), then the debugger is even more of a pain.

I've worked on TS on large existing projects as part of large teams. In my last project, we did have some sort of file system watcher but it still took > 10 seconds on average to compile. Launching the project from scratch took longer than 1 minute. From time to time, I did have to relaunch the whole app; usually for a different reason every time.

I have been working now for 2 years with Typescript on a heavy SPA in combination with ASP.Net / AngularJS 1.5 components, and absolutely love it. I have zero compiler issues. We started with plain javascript but switched to Typescript later on, and it still amazes me how many small mistakes we made that have been preventing by just adding typing. Automatic Refactoring and Find Usages alone are worth 10x the small delay in compilation.

The biggest gripe I have is that Chrome debugging is hell, because sometimes it will recognized the typescript, sometimes only the javascript. I have hit Ctrl-P many times to "establish" mappings between files running in IIS Express and local files. Miss and hit.

I use console.log all the time so I don't understand your comment in that regard. It works perfectly fine with Typescript.

Ah yes I had forgotten about the source map issues. My point is there is almost always something wrong with it depending on the project. The source maps issues are pretty serious.

Not having the same code on paper and on machine so to speak does make debugging typescript a little hard. It's a little bit of a black-box.

I code typescript for Angular 2/4, and although yeah, the aforementioned debugging pains are annoying, the time saved on having types to enable linting and strong predictable variable comparisons, is much greater.

Also, needing console.logs everywhere should be discouraged. Your code should be clear enough that you don't need a console.log debug line to print the boolean result of a comparison, for example. This is the whole point of typescript like I said, to make variable comparision and management easier so that you don't need that console.log line...

I don't mean leaving console.log everywhere, just when debugging, when you want to check the value of a specific variable quickly without having to click around in the debugger.

Developers from statically typed backgrounds just don't seem to understand this use case. It's the quickest way to find an issue when you have a good idea of where the problem might be.

I suppose. I come from the C and C++ world, before I moved onto webdev (quite rare for a young millennial like me to be dinkling around with static C-related languages, I've been told by older colleagues), so I guess that I don't see it from the most understanding point of view.

I also used a fair bit of C/C++ in the past, the debugging process feels very different to me. It's definitely much slower but in that case it's worth it because of the flexibility you get out of it.

When you use Javascript for a few years, your habits change and you get used to really quick debug iterations. With Typescript, you get slower debug iterations but you don't get any extra flexibility beyond what Javascript itself offers. No pointers, no threads, no low-level access to system calls, no custom memory allocation, no performance gains... It doesn't have any of the features that make C/C++ an awesome language.

No, we understand that use case.

It's just usually indicative of code that can only be understood by running it.

Good statically typed code can be understood by reading it.

This is the first negative comment I've ever heard about TypeScript, which makes it really interesting. I thought it was all praise.

You don't need years of trials. One thing that people forget is that types are a parallel ecosystem more times than not i.e. DefinitelyTyped. So you do not have that lock-step that is praised. So imagine wanting to use a brand new webextension api - stop, add it to types. Want to upgrade a dependency - stop, the types are not working/incorrect/incomplete e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/issues/17...

AFAICS the Typescript types ecosystem is bigger simply because Typescript has been advertised to devs coming from a background of a statically typed lang, and they cannot imagine not using types, thus they drown in them.

Flow on the other hand appeals to those that want types primarily in their own codebase, and come from inferred/dynamically typed langs, where you gradually add static types starting with key sensitive parts in your codebase e.g. Erlang http://learnyousomeerlang.com/types-or-lack-thereof

I think some developers have had a grudge with Javascript since the dawn of time and just cannot move past it. They'd rather move mountains than try to adapt to the environment.

Definitelytyped is frustrating; sometimes they have the type definitions sometimes not. Often the definitions are out of date and new ones are not available. Sometimes I feel that it's better not to use it at all... That way I don't have to think about it.

You don't have to add types to start using a new library or web extension. At most you have to add 'declare var foo: any;' or cast a builtin to any if the type declaration doesn't have the property you need. Typesript always lets you use the any type as an escape hatch if you don't have types.

What about using the TypeScript toolchain as a JavaScript static analyis tool without actually writing in TypeScript? (tsc can still verify your js files are minimally 'correct' through type-inference, for example).