4 ms·

I've worked with TypeScript on and off for a couple of years now. I don't like it. The compilation step is a major pain. Even after using it for several months

I've worked with TypeScript on and off for a couple of years now. I don't like it. The compilation step is a major pain. Even after using it for several months straight, I feel like I'm in a constant battle with the compiler. 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); 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. I have gone back and forth from dynamically typed languages to statically typed languages many times for years and I've spoken with engineers who used to be Java developers for many years, then switched to Javascript, then TypeScript and they shared the same thoughts as I did. TypeScript is slow and restrictive in a way that is unnecessary. It's got Microsoft all over it. 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. At my previous work, even developers who said that they liked TypeScript secretly didn't like it because they used the 'any' type Everywhere. I wonder if the people who are making this decision have actually tried TypeScript themselves for any decent amount of time on a decent sized project. I don't think they know what they're getting into. I decided not to renew a lucrative contract at a finance firm as a front-end developer in part because I did not enjoy using TypeScript every day.

DaiPlusPlus 9y ago
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).
- deleted 9y ago
  [deleted]
Kiro 9y ago
This is the first negative comment I've ever heard about TypeScript, which makes it really interesting. I thought it was all praise.
- andreineculau 9y ago
  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/17360 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 http://learnyousomeerlang.com/types-or-lack-thereof
  - jondubois 9y ago
    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.
  - sesutton 9y ago
    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.
rogihee 9y ago
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.
- jondubois 9y ago
  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.
deleted 9y ago
[deleted]
zucchini_head 9y ago
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...
- jondubois 9y ago
  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.
  - zucchini_head 9y ago
    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.
    - jondubois 9y ago
      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.
octref 9y ago
> 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/ https://code.visualstudio.com/
- jondubois 9y ago
  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.

DaiPlusPlus 9y ago

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

deleted 9y ago
[deleted]

Kiro 9y ago

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

andreineculau 9y ago
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/17360 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 http://learnyousomeerlang.com/types-or-lack-thereof
- jondubois 9y ago
  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.
- sesutton 9y ago
  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.

rogihee 9y ago

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.

jondubois 9y ago
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.

deleted 9y ago

[deleted]

zucchini_head 9y ago

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

jondubois 9y ago
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.
- zucchini_head 9y ago
  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.
  - jondubois 9y ago
    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.

octref 9y ago

> 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/ https://code.visualstudio.com/

jondubois 9y ago
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.