DEV Community

Discussion on: Key Headaches in TypeScript

 
bytebodger profile image
Adam Nathaniel Davis • Edited

Yeah... this. Sooooo much this.

I've been writing JS for a while now and type issues aren't generally something I run into. I understand and appreciate the flexibility of JS and its dynamic typing. A lot of developers I know see it as a hindrance to better code, but after rewriting this library in TS, I'm still not really convinced.

Exactly. For years, before I was writing any TS code, one of my common retorts to the TS crowd was that dynamic typing isn't a bug. It's a feature. Can it cause problems sometimes? Sure. But these aren't problems that I typically run into. And now that I'm diving into TS, it seems to be causing its own "class" of problems...

I'm not hating on TS. I'm definitely not saying it's "bad". But neither do I believe it's the kinda panacea that some devs seem to characterize it as.

The real benefit of TS would be if it did type checking at RUNTIME, but since it doesn't, it kinda seems pointless in many cases.

BINGO! I've even got a few articles queued up in my head around this exact topic. Even though I knew, on some level, that TS was purely a compile-time tool, the limitations of that didn't really slap me upside the head until I started writing TS. You see, in my code, I'm accustomed to adding many runtime checks. In my functions, there are many cases where I actually want the app to throw an exception or, at a minimum, to return out of the logic if the proper value types have not been provided.

But all of my runtime checks are still required in TS - cuz ultimately, TS doesn't even really "exist" at runtime.

but if you're using an external API and they changed something you didn't anticipate

Double BINGO! Basically, if you're dependent upon any kinda side-effects - API data, database data, state data, etc. - none of those lovely TS type declarations are gonna do you much good.

TS definitely didn't make his code easier to understand - quite the opposite.

<NoddingHead/> Even in some of my early TS articles, there have been some (awesome) people who've helpfully been chiming in with their code examples. And of course, I totally appreciate that! But sometimes you look at their solutions and they look a lot like complex regular expressions.

In fact, the more TS I do, the more I feel like RegEx is a useful analogy. RegEx is powerful. At the right time, RegEx can absolutely be the "right tool for the job". And of course, there are some things that you simply can't do without RegEx. But anyone who tells me that RegEx is easy to read is just a hardcore RegEx jockey. Even after 20+ years in this career field, there are still some times when I have to do a "deep think" whenever I'm trying to parse someone else's regular expression. TS is often the same.

I think TS has a place in some applications but typing things just because is a little silly.

I agree. And I think that I'm already having a bit of a problem with this. You see, a big part of my dev brain says, "Well, if you're gonna use TS, and TS is all about typing, then you should type ALL THE THINGS!!!" To haphazardly type some of the things, but not others, feels kinda arbitrary to me. On the other hand, I totally understand what you're getting at in this comment. It can be challenging to decide how much typing is the "right amount" of typing.

but I'd say about 60% of the time was spent writing Interfaces to correctly pass the right types so TS wouldn't complain, not actually writing logic

Exactly. Hence my observation (which was actually stolen from another commenter) that far too much time can be spent simply explaining - to the compiler - the code you had that was already working just fine.