5 ms·

> It's not worth it. Productivity will drop enormously How does TypeScript make your "productivity drop enormously"? It has type inference, union types, looks

by naiyt 8y ago

> It's not worth it. Productivity will drop enormously How does TypeScript make your "productivity drop enormously"? It has type inference, union types, looks just like ES6, and the typing is fully optional. The learning curve is quick if you've ever done static typing before (and not that hard even if you haven't). And you get the productivity boost of not dealing with a lot of the regular JavaScript BS (no more "spooky undefined at a distance" because somebody forgot a 3rd parameter 4 methods down the callstack), as well as the ability to safely and automatically refactor, and the ability to immediately understand the API of other people's code or libraries (as long as it's typed, and most popular libraries have type definitions now). In my experience the productivity benefits more than make up for the time you spend managing your types.

jondubois 8y ago
>> How does TypeScript make your "productivity drop enormously - 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 and especially if you're not used to having a build step during development. - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. - 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. - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. - 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. - 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. - 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. - 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. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic and coming up with meaningful abstractions which don't require arbitrary constraints to be imposed. - Setting up TypeScript is a pain. - 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.
- jacobr 8y ago
  Can confirm most of these points, but still believe TypeScript is a net positive for productivity, when you consider things like refactoring tools (VS Code). And on top of that add increased safety, less bugs and improved code quality because if you encounter something problematic you will actually dare improve it, because things are much less likely to break.
- naiyt 8y ago
  Thanks for details. Here's my response to most of them (some of this is definitely anecdotal of course). > - Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up. I've not personally encountered any significant compiling overhead in comparison to a regular Babel ES6 transpile. Obviously depends on project size, but there are a lot of tweaks that you can do to speed it up. I've had good luck with ts-loader. > - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. Are you advocating ES6 instead of TypeScript? It seems like all modern JS hits a transpilation stage before it hits the browser these days, and I see the same source mapping issues whenever I use ES6/7 with Babel + Webpack. > - 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. Fair point, although I haven't run into this much myself. > - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). Not sure I follow, do you have an example? > - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. I mostly agree with this, which is why my strategy is just to do regular JS style schema validation where necessary, and then cast the object, rather than relying on `unknown`. > - 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. Not sure I fully follow. If your code compiles to the point where you can use the debugger, you should have been able to use a console.log as well, right? > - 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. If you're writing code used by others, you need to be clear about what your API expects and allows anyway, so why not be explicit about it, in a way that the compiler can enforce? An intelligent person makes mistakes, so why not see if you can give the computer the ability to catch some of those for you? And TypeScript still gives an intelligent user the ability to supersede your type restrictions if they absolutely need to. > - 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. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic only. I don't think coming up with good interface names is more difficult than good class or method names. And I'd argue that thinking about the constraints you want to impose on users is important for developing maintainable code -- whether you're doing type checking or not. And ultimately those constraints still have to exist in some manner, but without type checking the "constraint" will be the code breaking in some undefined way. By doing so you save yourself and others the mental overhead of trying to figure out what types you're dealing with at any point in your code base, or what types you're expected to pass into any given function. The initial overhead of thinking about your types pays off quickly. > - Setting up TypeScript is a pain. Anecdotal, but I've never had much of a problem with it (for React users, I believe you can get it for free in create-react-app now). And it's a one time setup cost anyway.

by naiyt 8y ago

jondubois 8y ago

>> How does TypeScript make your "productivity drop enormously - 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 and especially if you're not used to having a build step during development. - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. - 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. - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. - 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. - 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. - 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. - 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. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic and coming up with meaningful abstractions which don't require arbitrary constraints to be imposed. - Setting up TypeScript is a pain. - 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.

jacobr 8y ago
Can confirm most of these points, but still believe TypeScript is a net positive for productivity, when you consider things like refactoring tools (VS Code). And on top of that add increased safety, less bugs and improved code quality because if you encounter something problematic you will actually dare improve it, because things are much less likely to break.
naiyt 8y ago
Thanks for details. Here's my response to most of them (some of this is definitely anecdotal of course). > - Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up. I've not personally encountered any significant compiling overhead in comparison to a regular Babel ES6 transpile. Obviously depends on project size, but there are a lot of tweaks that you can do to speed it up. I've had good luck with ts-loader. > - Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind. Are you advocating ES6 instead of TypeScript? It seems like all modern JS hits a transpilation stage before it hits the browser these days, and I see the same source mapping issues whenever I use ES6/7 with Babel + Webpack. > - 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. Fair point, although I haven't run into this much myself. > - Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements). Not sure I follow, do you have an example? > - Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript. I mostly agree with this, which is why my strategy is just to do regular JS style schema validation where necessary, and then cast the object, rather than relying on `unknown`. > - 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. Not sure I fully follow. If your code compiles to the point where you can use the debugger, you should have been able to use a console.log as well, right? > - 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. If you're writing code used by others, you need to be clear about what your API expects and allows anyway, so why not be explicit about it, in a way that the compiler can enforce? An intelligent person makes mistakes, so why not see if you can give the computer the ability to catch some of those for you? And TypeScript still gives an intelligent user the ability to supersede your type restrictions if they absolutely need to. > - 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. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic only. I don't think coming up with good interface names is more difficult than good class or method names. And I'd argue that thinking about the constraints you want to impose on users is important for developing maintainable code -- whether you're doing type checking or not. And ultimately those constraints still have to exist in some manner, but without type checking the "constraint" will be the code breaking in some undefined way. By doing so you save yourself and others the mental overhead of trying to figure out what types you're dealing with at any point in your code base, or what types you're expected to pass into any given function. The initial overhead of thinking about your types pays off quickly. > - Setting up TypeScript is a pain. Anecdotal, but I've never had much of a problem with it (for React users, I believe you can get it for free in create-react-app now). And it's a one time setup cost anyway.