5 ms·
I really don't understand why people are still using an inferior tool chain to build JavaScript in 2024. The type checking alone has the potential to save count
by zoover2020 2y ago
I really don't understand why people are still using an inferior tool chain to build JavaScript in 2024. The type checking alone has the potential to save countless of bugs.
I wish we could get rid of "vanilla js must imply going back in time 10 years" ideology because it's so unnecessary. Using typescript doesn't mean you have to go react or other libraries.
- leptons 2y agoeh... so far Typescript hasn't saved us from any bugs, but YMMV.
- methodical 2y agoDitto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV
- digging 2y agoEven if that's true (maybe your team is really careful about documentation and data structures even when they don't have types?) - the majority of the "bugs" TS catches are those that would be caught manually anyway, during development. It's just that instead of measuring those bugs in hours, they don't even exist to be measured.
- meiraleal 2y ago> It's just that instead of measuring those bugs in hours, they don't even exist to be measured. hours beautifully wasted configuring, updating, getting beaten by a myriad of build tools, configs, breaking changes, wrong/any types all everywhere. No, thanks.
- digging 2y agoThe eternal question of spending "x hours upfront" vs "x/2 hours every single day"...
- leptons 2y agoI have a feeling you made up "x/2 hours every single day".
- digging 2y agoYes, I did. What's the correct denominator that makes the daily effort worthwhile for you? Would you do x/5? x/10? x/50? After 50 days of continuously spending more effort than necessary, do you make the trade or just accept the ever-increasing loss of productivity? Fortunately for us all, the real number for "configure Typescript" is a lot closer to 1 than to 50.
- leptons 2y agoTypescript is not saving me x/2 of the usual time I spend coding, not even close, not even in the ballpark. It's more like costing me 10% of my time due to missing types in libraries, hassle of extra tooling, more complexity, compilation step, etc, etc. Yes, I made that up that 10% figure, but I wouldn't be surprised if it's close to that. If you're prone to making easy to avoid errors in your code, then maybe Typescript will save you time. For me, that is not the case. YMMV.
- digging 2y agoYou don't think a tool saving 10% of your time is worth learning to use?! Anyway, this gets off-track. The metric is (time wasted on problems that only exist without typing) / (time it takes to configure TypeScript). Regardless of what your 10% figure is, learning TypeScript and configuring it for a project takes less time. > If you're prone to making easy to avoid errors in your code, then maybe Typescript will save you time. For me, that is not the case. YMMV. Putting aside the dig, it sounds like you're working alone, so use whatever you want. It matters a lot less when you control the data structures and hold the entire program in your own head.
- ervine 2y agoAre you using strict mode?
- ervine 2y agoJust knowing wtf an API response shape the app is expecting, or what the shape of a function argument object is... I can't imagine arguing against TypeScript (or whatever thing documents the shape of your data as it moves through your app).