Oh, man... good thoughts and good feedback. I think I agree with everything here, and I won't regurgitate it, but there are a few points that struck me:
But what is compelling about Typescript typing is that intellisense works as we type.
I sooooo get this. About 7 years ago, I was writing a lot of PHP code in my free time on a huge side project. As I tended to do every couple of years, I reached a point where I said, "Let me reassess the IDE options that are out there." And that was the first time that I stumbled across JetBrains (and their PHP-specific IDE, PHPStorm). It's not an exaggeration to say that it transformed my code. Because PHPStorm was the first IDE I ever found that did an amazing job of discovering all of my loosely-inferred types in PHP. And once I realized that the IDE could ferret this stuff out, it incentivized me to actually write code that would better "mesh" with PHPStorm. And when I say that it "meshed" with PHPStorm, what I'm really saying is that my code became much more explicit in broadcasting to the IDE (or to other devs who found themselves slogging through my code) exactly what type of variable they were looking at.
Finally there are 30 years worth of strong typers around. They are very comfortable with Typescript; which, allows them to ramp up much faster.
I'm nodding my head. And I'm also a little bit chagrined. As one of those "grey-beard" developers, I can tell you, in React, what really groks in my mind - class-based components. They just kinda... make sense. I don't have a "problem" with function-based components. But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".
But I know some hardcore TS fans who will try to shout you down over the use of that ugly, nasty, unthinkable class keyword in their React components...
Strong typing brings discipline to the table and it stops ambiguity of the untyped Javascript Object. Do we absolutely need it ? No, but some of us want it.
I totally understand and respect this comment. Good points - all of them.
Your statement on finding a tool that really helped and incentivized you to 'lean into it to get more out of it', resonates with me (to the moon and back).
My first experience with this concept was back in 1988. I had put out a production bug that cost millions to fix. I was so upset at myself I went to their huge on campus tech library and checked out every book they had on software testing. This book changed my carrier and confidence levels.
I learned how Unit Testing objectives made my code bullet proof. So I leaned into the concept more and more thoughout my career. It was a major boost all the way around.
Today, I still willingly embrace unit test, as there's no substitute for it.
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.
Oh, man... good thoughts and good feedback. I think I agree with everything here, and I won't regurgitate it, but there are a few points that struck me:
I sooooo get this. About 7 years ago, I was writing a lot of PHP code in my free time on a huge side project. As I tended to do every couple of years, I reached a point where I said, "Let me reassess the IDE options that are out there." And that was the first time that I stumbled across JetBrains (and their PHP-specific IDE, PHPStorm). It's not an exaggeration to say that it transformed my code. Because PHPStorm was the first IDE I ever found that did an amazing job of discovering all of my loosely-inferred types in PHP. And once I realized that the IDE could ferret this stuff out, it incentivized me to actually write code that would better "mesh" with PHPStorm. And when I say that it "meshed" with PHPStorm, what I'm really saying is that my code became much more explicit in broadcasting to the IDE (or to other devs who found themselves slogging through my code) exactly what type of variable they were looking at.
I'm nodding my head. And I'm also a little bit chagrined. As one of those "grey-beard" developers, I can tell you, in React, what really groks in my mind - class-based components. They just kinda... make sense. I don't have a "problem" with function-based components. But soooo many times, the class-based paradigm seems to better "fit" what React defines as a "component".
But I know some hardcore TS fans who will try to shout you down over the use of that ugly, nasty, unthinkable
classkeyword in their React components...I totally understand and respect this comment. Good points - all of them.
Adam...
Your statement on finding a tool that really helped and incentivized you to 'lean into it to get more out of it', resonates with me (to the moon and back).
My first experience with this concept was back in 1988. I had put out a production bug that cost millions to fix. I was so upset at myself I went to their huge on campus tech library and checked out every book they had on software testing. This book changed my carrier and confidence levels.
I learned how Unit Testing objectives made my code bullet proof. So I leaned into the concept more and more thoughout my career. It was a major boost all the way around.
Today, I still willingly embrace unit test, as there's no substitute for it.