4 ms·
I think this depends on where you are measuring costs in your codebase. If you're strictly looking at time to market on your first iteration, then you're right,
by tmountain 7y ago
I think this depends on where you are measuring costs in your codebase. If you're strictly looking at time to market on your first iteration, then you're right, types are going to require more of your team's time up front. If you look at the total lifespan of a "real project", then type safety is likely going to represent a cost savings regarding time your team spends on bug fixes, refactoring, and maintaining legacy portions of your app.
For context, I base the above sentiment on our team's last two years of effort in migrating key parts of our app to TypeScript (25 devs, ~500k lines of code). We've found that it has substantially reduced the number of defects that make it into production, and it has also reduced the number of round trips through QA. Clearly, this is only one data point, but hopefully it offers some perspective on why TS can be valuable in a codebase.
- nocommentx 7y agosounds like its working for you, so i'm glad. you're about what i'd consider a big team / codebase. i can't recommend TS to people trying to create product from nothing. if your startup is doing well, you can hire someone to annotate your code w/ types later ;)
- gregplaysguitar 7y agoMy experience is the opposite. One of the best things about TS is yhe refactoring experience - change a function signature for example and TS will tell you all the places you need to update. In a fast moving greenfields project with various requirements in flux, I’ve found this invaluable
- tmountain 7y agoI agree on this too. Oftentimes, we'll change a type and then just follow the errors in VSCode. It's a pretty great way to track down all the codepaths that are affected really quickly.