Similar experience here. We decided to adopt TS on a library rewrite after looking at the code beforehand and realizing there was a lot of weird things happening and it wasn't really clear HOW things were still working 🤣
I think TS definitely helped me understand the code as I was rewriting it, but I'm honestly not sure that it really made the code less error prone. 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.
Don't get me wrong, the extra documentation we gain from having TS in the IDE is pretty awesome, but I don't know if I'd want to use TS on everything. On this library, it worked well and I think the annoyances were worth the effort, but if I were using it inside our UIs, I feel like it'd add more overhead than it's worth.
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. If you're able to have control over all your own data, it's one thing, but if you're using an external API and they changed something you didn't anticipate, your code would still have the same issues as it would've without TS.
Moreover, I think the pitfall many developers fall into with TS is over-typing everything. One of our junior devs worked on a specific class and functionality in our rewrite and when I went to code review it, TS definitely didn't make his code easier to understand - quite the opposite. I think TS has a place in some applications but typing things just because is a little silly.
FWIW, our library also went from ~6 files to over 80 with TS. It's definitely more organized than before (it would've been more files, regardless), 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 😋
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.
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.
Similar experience here. We decided to adopt TS on a library rewrite after looking at the code beforehand and realizing there was a lot of weird things happening and it wasn't really clear HOW things were still working 🤣
I think TS definitely helped me understand the code as I was rewriting it, but I'm honestly not sure that it really made the code less error prone. 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.
Don't get me wrong, the extra documentation we gain from having TS in the IDE is pretty awesome, but I don't know if I'd want to use TS on everything. On this library, it worked well and I think the annoyances were worth the effort, but if I were using it inside our UIs, I feel like it'd add more overhead than it's worth.
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. If you're able to have control over all your own data, it's one thing, but if you're using an external API and they changed something you didn't anticipate, your code would still have the same issues as it would've without TS.
Moreover, I think the pitfall many developers fall into with TS is over-typing everything. One of our junior devs worked on a specific class and functionality in our rewrite and when I went to code review it, TS definitely didn't make his code easier to understand - quite the opposite. I think TS has a place in some applications but typing things just because is a little silly.
FWIW, our library also went from ~6 files to over 80 with TS. It's definitely more organized than before (it would've been more files, regardless), 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 😋
Yeah... this. Sooooo much this.
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.
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
returnout 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.
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.
<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 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.
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.