daniel-octomindI’m firmly in the TypeScript camp. I believe it enhances code readability, maintainability, and reduces bugs and for full disclosure, I've written only about 0.1% of vanilla JavaScript versus TypeScript. Yet, I DON'T assume the authority to dictate how someone should run their open-source project or approach their software development.
However, using typescript is also not an absolute, and some of the arguments brought up against it have some merit.
"TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become
any."~ DHH in Turbo 8 is dropping typescript
I agree, sometimes, types are super hard. But going TypeScript doesn't mean going all in. It’s absolutely okay to introduce it iteratively, just like we all strive to develop software in an agile fashion. I would argue it will still help in making the code more readable.
For example, let’s take the popular tanstack-query ts library code (shoutout to them, a pleasure to work with!) for constructing a query on the client side to fetch some server data:
Certainly some “gymnastics” there with a 4-time generic and triple overload. I think even the most staunch TS supporters would take a second to grok what the octopus is going on here. (the return type of the function basically depends on the type of options you pass in).
It’s obviously great to have the types being so exact and generic, but I would argue that even a more basic version of the types already provides value to your users. Especially what options to pass is already greatly helpful (there’s a lot).
Now, it’s likely there will be some cursing and type-casting on the user’s side, but this is still better than no typing. It’s completely fine to use any and you don’t need to do the ‘full thing’ if you are in a rush. Even the TypeScript docs itself suggest:
“The
anytype is useful when you don’t want to write out a long type just to convince TypeScript that a particular line of code is okay."
Though, if you're always in fire-fighting mode and never have time to make the types work, there’s probably deeper issues with your project's operational tempo, but I digress.
Do what works for you and the particular situation. I think it’s always worth investing those extra 30 minutes to figure out the types to make the life easier for the next developer looking at the code. But it’s all a spectrum and you can approach it iteratively just like everything else. Ultimately, the goal is delivering value sustainably and maintainably.
Something we often overlook in engineering: Software has a purpose, right? It’s about delivering value to your user and customer. If you can pull that off without static typing, good on ya. Personally, I wouldn’t enjoy working on that project, but hey, to each their own.
I can always... not. 🙂
Daniel Draper
Lead engineer at Octomind
