As your journey continues, I'm beginning to wonder why again... What is nirvana here? Somewhere down the road, a developer won't accidentally call something with an incorrect parameter? Then they don't notice, and something gets released with a bug. Is that it? Do we have examples of where this happened a lot, and people had disasters that have gone away and that productivity has increased? I'm sure we have anecdotes, but I'm wondering if since TS the web is suddenly a more productive place in terms of output - for sure everyone writing TS is writing a lot more words into their script.
For a while, I've been saying, oh, we can use some TS soon. Write some modules in it; we can use the typings from the JSDoc, etc. Now it's starting to feel like a way of getting people from other languages to feel "comfortable" rather than benefitting from the speed of authoring and terseness of pure JS. But maybe I'm just grumpy today. I should point out I don't type ";" because they slow me down, so I'm probably a basket case already.
Or do we think a set of documentation that tells you "what not why" is going to be helpful? You know, JSDoc has all of the types, but it also has examples, descriptions of the purpose, etc. I'm beginning to think of TypeScript as the latest version of JScript - one of Microsoft's disastrous attempts to own the language, causing years of pain for developers writing five versions of everything.
I guess if I had 1000s of developers and some of them were slapdash and junior, then it might help. However, I architect all of my systems to use loose coupling and minimal imperatives between modules. It seems to solve a lot more problems.
I'm with you. Speaking for myself, I'm doing this because the current project will be in TS and the lead on the project loves TS and the other devs on the project love TS. So... I'm using TS. And maybe my attitude will change on it in a few months, but right now I'm having a really hard time seeing the benefit.
I've found it striking how much some people swear by it though. We had a little group discussion about it on our team because one of the other senior guys questioned why we're using TS. It turned out that, basically, all of the "younger" guys were strongly in favor of TS. And to be honest, it felt a little like hearing people who are brainwashed, cuz they all spoke with general statements about how things were "easier" or "cleaner" or had fewer bugs in TS - but these were all general platitudes with little in the way of empirical evidence. So we're using TS...
Here's the ironic thing. Several of the guys are new to React. (Whereas I'm basically the opposite - very senior in React, but new to TS.) But they're running into some of the same head-scratchers. I was hoping that, as guys with much more TS experience, they'd look at what's driving me nuts and say, "Oh, yeah - you just need to do it this way." But they're not doing that. They're stumbling over some of the same things.
Your point about JSDoc is very interesting. When you wrote that in a previous blog comment, it kinda caught me off guard. I was thinking, "Well, regardless of what you think of TS, you can't really compare it to JSDoc cuz JSDoc is really just like... linting. I mean, it doesn't actually do anything in your code. It basically just 'speaks' to your IDE to help with your coding." But then I realized that, in many respects, that's what TS is doing, right?? I mean, TS just compiles down to plain ol' JS. All that TS "magic" is really just there to help you hook things up in your IDE.
Your last paragraph is perhaps most telling. I think that, perhaps, some of my resistance to TS is that I'm (too) senior, and a lot of what TS is trying to "fix" is stuff that I've already figured out how to fix just by writing better code. I'm still open to the idea that maybe TS is better than I think it is once we account for the fact that most devs on a team will not have 20+ years of experience.
I think you put your finger on my problem here. I understand why I need strong types in C++, it's because I am in control of the memory allocated for every single variable and what it's doing and exactly how it will be interpreted by the function which receives it. That's all just a sham in TS, it is only there for linting. IntelliJ does interpret JSDoc and dynamically compiles my code and warns me if I'm using the wrong variable. But I only have to do it when I want to. Maybe that's the problem... you have no choice in TS so you can't short cut it.
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.
As your journey continues, I'm beginning to wonder why again... What is nirvana here? Somewhere down the road, a developer won't accidentally call something with an incorrect parameter? Then they don't notice, and something gets released with a bug. Is that it? Do we have examples of where this happened a lot, and people had disasters that have gone away and that productivity has increased? I'm sure we have anecdotes, but I'm wondering if since TS the web is suddenly a more productive place in terms of output - for sure everyone writing TS is writing a lot more words into their script.
For a while, I've been saying, oh, we can use some TS soon. Write some modules in it; we can use the typings from the JSDoc, etc. Now it's starting to feel like a way of getting people from other languages to feel "comfortable" rather than benefitting from the speed of authoring and terseness of pure JS. But maybe I'm just grumpy today. I should point out I don't type ";" because they slow me down, so I'm probably a basket case already.
Or do we think a set of documentation that tells you "what not why" is going to be helpful? You know, JSDoc has all of the types, but it also has examples, descriptions of the purpose, etc. I'm beginning to think of TypeScript as the latest version of JScript - one of Microsoft's disastrous attempts to own the language, causing years of pain for developers writing five versions of everything.
I guess if I had 1000s of developers and some of them were slapdash and junior, then it might help. However, I architect all of my systems to use loose coupling and minimal imperatives between modules. It seems to solve a lot more problems.
I'm with you. Speaking for myself, I'm doing this because the current project will be in TS and the lead on the project loves TS and the other devs on the project love TS. So... I'm using TS. And maybe my attitude will change on it in a few months, but right now I'm having a really hard time seeing the benefit.
I've found it striking how much some people swear by it though. We had a little group discussion about it on our team because one of the other senior guys questioned why we're using TS. It turned out that, basically, all of the "younger" guys were strongly in favor of TS. And to be honest, it felt a little like hearing people who are brainwashed, cuz they all spoke with general statements about how things were "easier" or "cleaner" or had fewer bugs in TS - but these were all general platitudes with little in the way of empirical evidence. So we're using TS...
Here's the ironic thing. Several of the guys are new to React. (Whereas I'm basically the opposite - very senior in React, but new to TS.) But they're running into some of the same head-scratchers. I was hoping that, as guys with much more TS experience, they'd look at what's driving me nuts and say, "Oh, yeah - you just need to do it this way." But they're not doing that. They're stumbling over some of the same things.
Your point about JSDoc is very interesting. When you wrote that in a previous blog comment, it kinda caught me off guard. I was thinking, "Well, regardless of what you think of TS, you can't really compare it to JSDoc cuz JSDoc is really just like... linting. I mean, it doesn't actually do anything in your code. It basically just 'speaks' to your IDE to help with your coding." But then I realized that, in many respects, that's what TS is doing, right?? I mean, TS just compiles down to plain ol' JS. All that TS "magic" is really just there to help you hook things up in your IDE.
Your last paragraph is perhaps most telling. I think that, perhaps, some of my resistance to TS is that I'm (too) senior, and a lot of what TS is trying to "fix" is stuff that I've already figured out how to fix just by writing better code. I'm still open to the idea that maybe TS is better than I think it is once we account for the fact that most devs on a team will not have 20+ years of experience.
I think you put your finger on my problem here. I understand why I need strong types in C++, it's because I am in control of the memory allocated for every single variable and what it's doing and exactly how it will be interpreted by the function which receives it. That's all just a sham in TS, it is only there for linting. IntelliJ does interpret JSDoc and dynamically compiles my code and warns me if I'm using the wrong variable. But I only have to do it when I want to. Maybe that's the problem... you have no choice in TS so you can't short cut it.
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.