> Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up - Especially on large projects.
But you can have decreased tests because you have to test for common typing issues. A lot of my PHP tests are type-checks.
> Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library.
I've had this happen with a very obscure library that was partially-typed by someone (god bless their soul) but it took me only a few minutes to manually make the changes to the definition.
> Doesn't guarantee type safety at runtime
That's not the purpose of the product though. It's like complaining you can't cook a turkey in the microwave; It's true, it would be a nice, but it certainly doesn't mean microwaves are bad -- they're just for a different purpose.
> Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing.
Constraints? I would call it documentation. I'm sure you're users would appreciate knowing what methods your class has and what the parameters are.
> Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.
Tell TypeScript to always generate the JavaScript code even on type errors and then you don't have to let it slow you down.
> The 'rename symbol' feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up.
I think it's a good reason to avoid storing identifiers in strings which is an anti-pattern in any language. Either way, you have this problem without TypeScript. Because it doesn't solve every problem that makes a poor excuse to keep it from solving some problems.
> It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one.
I agree totally! It's never been easier to refactor and rename than with a strongly typed language. Admittedly I haven't done too much work making these big changes in TypeScript but definitely have done it with C#/Java and compared to dynamic languages the speed you can make correct changes is amazing. You can see your mistakes as you type with good tooling.
> Setting up TypeScript is a pain.
I've setup a complete modern JavaScript tool setup and setting up TypeScript is by far the easiest part of that.
> Adds a lot of dependencies and complexity. It's a miracle that TypeScript works at all given how much complexity it sweeps under the carpet. Have you looked at the output JavaScript? Try to compile something that uses async generators and see what the output looks like.
That's what async generators do. They do the same thing in other languages (just look at the disassembly). It automates creating a state machine. I don't see why anyone would want to write a state machine themselves rather than let the compiler do it for you. It's actually difficult enough that most people wouldn't do it even though it's a great programming pattern.
>> I've setup a complete modern JavaScript tool setup and setting up TypeScript is by far the easiest part of that.
I see what you mean. Maybe that is the root of the problem and the reason for TypeScript's increasing popularity. The fact that the author of the article mentioned Flow also suggests that there is a similar effect at play in his case; devs get used to the build step and since they're already spending time building JS, they might as well start building TS.
I hate bundling during development so I'm not used to waiting around when debugging. Unfortunately, most modern front-end coding approaches depend on having a bundling step during development. I guess front end development is in a bad state right now. I tried VueJS a few months ago and I was shocked at how difficult it was to find information on how to use it without the bundling step. I was able to figure it out eventually and it turned out to be a very nice framework but the information necessary to get that ideal setup was just not there.
I'm not a fan of bundling/packing obsession either, but I've come to recognize its necessity, at least at present. If you want to use any external libraries in a reliable way, or don't want to serve massive, incompatible-with-some-browsers JS files, I just don't think there's currently a way around using some sort of bundler (or, alternatively, paying the cost in slowed-down development and/or stacks of compatibility-related annoyances based on the "modern"-ness of any code you write or import). For tiny projects you may not need one, but beyond that the convenience benefits are just too great.
Every time I've tried to avoid using a bundler in development, I've either regretted it (babel/webpack/whatnot has screwed something up in prod that I didn't catch in dev), or ended up shoving the important parts of a bundler into browser plugins that roughly execute the bits of the build phase I care about in the browser when the page loads.
I feel you. I've just starting a project from scratch using modern JS development stack including TypeScript. I've previously just done by JS without any tooling at all (besides an IDE). And I have used TypeScript stand-alone without the rest of JS bundling infrastructure.
I also used to do more dynamic back-end development (PHP) but a long time now my backend work has been C#.
The future of JavaScript, probably the future of web development in general, is with a compilation/build step. Having a fully dynamic uncompiled front-end and back-end code was probably just temporary blimp. The tooling, though, already understands your concerns and has plenty of features for editing and running without noticing the build step. I could configure the TS build environment to re-load scripts on edit and I don't even have to press refresh in the browser to see the effects.
It does all feel very heavily and complicated but sometimes I have to wonder if that's just me.
But you can have decreased tests because you have to test for common typing issues. A lot of my PHP tests are type-checks.
> Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library.
I've had this happen with a very obscure library that was partially-typed by someone (god bless their soul) but it took me only a few minutes to manually make the changes to the definition.
> Doesn't guarantee type safety at runtime
That's not the purpose of the product though. It's like complaining you can't cook a turkey in the microwave; It's true, it would be a nice, but it certainly doesn't mean microwaves are bad -- they're just for a different purpose.
> Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing.
Constraints? I would call it documentation. I'm sure you're users would appreciate knowing what methods your class has and what the parameters are.
> Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.
Tell TypeScript to always generate the JavaScript code even on type errors and then you don't have to let it slow you down.
> The 'rename symbol' feature supported by some IDEs is nice, but if a class or property is mentioned inside a string (e.g. in a test case definition) then it will not rename that; so I still have to do text search after doing a symbol rename and manually clean up.
I think it's a good reason to avoid storing identifiers in strings which is an anti-pattern in any language. Either way, you have this problem without TypeScript. Because it doesn't solve every problem that makes a poor excuse to keep it from solving some problems.
> It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one.
I agree totally! It's never been easier to refactor and rename than with a strongly typed language. Admittedly I haven't done too much work making these big changes in TypeScript but definitely have done it with C#/Java and compared to dynamic languages the speed you can make correct changes is amazing. You can see your mistakes as you type with good tooling.
> Setting up TypeScript is a pain.
I've setup a complete modern JavaScript tool setup and setting up TypeScript is by far the easiest part of that.
> Adds a lot of dependencies and complexity. It's a miracle that TypeScript works at all given how much complexity it sweeps under the carpet. Have you looked at the output JavaScript? Try to compile something that uses async generators and see what the output looks like.
That's what async generators do. They do the same thing in other languages (just look at the disassembly). It automates creating a state machine. I don't see why anyone would want to write a state machine themselves rather than let the compiler do it for you. It's actually difficult enough that most people wouldn't do it even though it's a great programming pattern.