Setting up Babel is (mostly) a one-time thing, and is generally mitigated by using bundlers such as Parcel (assuming you're working with the frontend). However, using TypeScript incurs a constant tax of about 20-40% of extra development time (in my experience), so definitely tread wisely.
Explain this “tax” objectively please. And do not cite Eric Elliot’s article since all of his citations have been refuted. The authors of his citations have come out publicly and stated that he is misusing their information to prove the opposite point. The original studies showed that static type checking does improve delivery time.
Like I said, this is "in my experience" :) I definitely am not speaking from statistical evidence. However, like the point I made in my article... writing TypeScript is definitively, provably longer than writing normal JavaScript, so if you are to defend TypeScript and how good it is, the burden of proof is on you to indicate that there is in fact a speed-up to using TypeScript vs. using JavaScript.
Sorry for not explicitly responding to your other items - some of them don't have a "Reply" button and I'm not sure why that is 🤷♂️ However on your other point regarding renaming a variable, I'm very curious... could you please describe how TypeScript specifically allows you to rename a variable better in 78 files than with regular JavaScript?
Webstorm can’t do this effectively in Javascript. Anyone who has tried that (as I have) will discover that WebStorm gets it wrong because it can only make guesses. However when you provide the IDE with the instrumentation of TypeScripts types then the IDE can be 100% accurate. Yes it’s an IDE feature (which I stated in my original message). So that’s why a failed refactor in JS would necessitate a regression tests of the system.
I think it’s wise to consider the trade-off between the initial development costs and then maintenance costs. That’s why I find comments like this concerning:
However, like the point I made in my article... writing TypeScript is definitively, provably longer than writing normal JavaScript
Yes, I can write it faster in JS. But when I fix one bug and it uncovered another bug... that takes more time in total. Each subsequent bug that’s created takes even more time. However, if you just wrote the app in TypeScript the first place then the subsequent bug fixes can be identified by the compiler. Which means:
less manual regression tests need to be run
bugs that are caught by the compiler are fixed before they even enter production
since you don’t have to fix production bugs you can do so with calmness. Doesn’t everyone want calmness and peace? I’d take that over initial development speed any day.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your response!
Setting up Babel is (mostly) a one-time thing, and is generally mitigated by using bundlers such as Parcel (assuming you're working with the frontend). However, using TypeScript incurs a constant tax of about 20-40% of extra development time (in my experience), so definitely tread wisely.
Explain this “tax” objectively please. And do not cite Eric Elliot’s article since all of his citations have been refuted. The authors of his citations have come out publicly and stated that he is misusing their information to prove the opposite point. The original studies showed that static type checking does improve delivery time.
Like I said, this is "in my experience" :) I definitely am not speaking from statistical evidence. However, like the point I made in my article... writing TypeScript is definitively, provably longer than writing normal JavaScript, so if you are to defend TypeScript and how good it is, the burden of proof is on you to indicate that there is in fact a speed-up to using TypeScript vs. using JavaScript.
Sorry for not explicitly responding to your other items - some of them don't have a "Reply" button and I'm not sure why that is 🤷♂️ However on your other point regarding renaming a variable, I'm very curious... could you please describe how TypeScript specifically allows you to rename a variable better in 78 files than with regular JavaScript?
Thank you for your time!
Right click “refactor > rename” and VSCode does the rest because it’s aware of TypeScript’s instrumentation of the code.
I can do that with regular JavaScript as well though... isn't this an IDE feature as opposed to a TypeScript feature?
Webstorm can’t do this effectively in Javascript. Anyone who has tried that (as I have) will discover that WebStorm gets it wrong because it can only make guesses. However when you provide the IDE with the instrumentation of TypeScripts types then the IDE can be 100% accurate. Yes it’s an IDE feature (which I stated in my original message). So that’s why a failed refactor in JS would necessitate a regression tests of the system.
I think it’s wise to consider the trade-off between the initial development costs and then maintenance costs. That’s why I find comments like this concerning:
Yes, I can write it faster in JS. But when I fix one bug and it uncovered another bug... that takes more time in total. Each subsequent bug that’s created takes even more time. However, if you just wrote the app in TypeScript the first place then the subsequent bug fixes can be identified by the compiler. Which means: