I'll always use TS for one reason and one reason only.
I am a lazy programmer.
I'm a lazy dev, and I wish JS+VSCode gave me better intellisense on the variables/interfaces I'm using, but it doesn't once you start including multiple files, or external data. When it does work, it actually is just using TS definitions under the hood anyways.
Its true TS isn't this a fool-proof safety-net that produces a false sense of security as its based on a "flawed" language model that can explode at any time during runtime due to my interfaces being wrong and me assuming the wrong stuff, and me being too lazy to check.
Id rather have a wonky interface than no interface. I don't know how many bugs I've created with my assumptions, and faulty pretenses, but I at least built something without split screening the docs, checking for typos every 5 seconds and building out a full test-suite of all edge cases for every function for full test coverage.
I'm sure the best of us will build the "perfect" kind of code that wont ever break because its been battle tested so it wont ever explode at run-time and can handle every and all errors perfectly, without using TS as a crutch. If your that kind of developer with that kind of resources, yes go ahead and make the jump.
I'm just a "lazy programmer" trying to make a deadline, and TS helps me get the job done faster with better intellisense, even if its "faulty" and makes my code "worse". Id rather have a faulty crutch than nothing.
I completely appreciate these sentiments. And though it may not be clear from the content of my article - I completely agree with these sentiments.
Obviously, I've personally come to believe that TS is not my favorite tool. And for me, it seems to cause more headaches than it's worth. But that's all... for me.
If TS is the right tool for you, then... by all means, use it! If it's the right tool for your team, or your company, or for the particular project on which you're currently working, then... use it! One of the common themes that runs through many of my articles is: Don't become dogmatic about any particular tool. Instead, always strive to use the right tool for the job.
Also, I'm acutely aware of the fact that my experience with "plain ol" JavaScript has somewhat skewed my opinion on this. If I were just starting out in web dev today, I might genuinely prefer TS. Hell, I might even prefer it because I too can be an incredibly lazy programmer.
But I've been doing this shit for long enough now that most of TS's "benefits" feel lost on me. There are all these additional hoops to jump through to accomplish what I was already doing in vanilla JS. But I am not everyone. Everyone is not me. And I'll gladly admit that, for a great many people, TS might absolutely be the right tool for the job.
Thanks for taking the time to comment!!
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.
I'll always use TS for one reason and one reason only.
I am a lazy programmer.
I'm a lazy dev, and I wish JS+VSCode gave me better intellisense on the variables/interfaces I'm using, but it doesn't once you start including multiple files, or external data. When it does work, it actually is just using TS definitions under the hood anyways.
Its true TS isn't this a fool-proof safety-net that produces a false sense of security as its based on a "flawed" language model that can explode at any time during runtime due to my interfaces being wrong and me assuming the wrong stuff, and me being too lazy to check.
Id rather have a wonky interface than no interface. I don't know how many bugs I've created with my assumptions, and faulty pretenses, but I at least built something without split screening the docs, checking for typos every 5 seconds and building out a full test-suite of all edge cases for every function for full test coverage.
I'm sure the best of us will build the "perfect" kind of code that wont ever break because its been battle tested so it wont ever explode at run-time and can handle every and all errors perfectly, without using TS as a crutch. If your that kind of developer with that kind of resources, yes go ahead and make the jump.
I'm just a "lazy programmer" trying to make a deadline, and TS helps me get the job done faster with better intellisense, even if its "faulty" and makes my code "worse". Id rather have a faulty crutch than nothing.
I completely appreciate these sentiments. And though it may not be clear from the content of my article - I completely agree with these sentiments.
Obviously, I've personally come to believe that TS is not my favorite tool. And for me, it seems to cause more headaches than it's worth. But that's all... for me.
If TS is the right tool for you, then... by all means, use it! If it's the right tool for your team, or your company, or for the particular project on which you're currently working, then... use it! One of the common themes that runs through many of my articles is: Don't become dogmatic about any particular tool. Instead, always strive to use the right tool for the job.
Also, I'm acutely aware of the fact that my experience with "plain ol" JavaScript has somewhat skewed my opinion on this. If I were just starting out in web dev today, I might genuinely prefer TS. Hell, I might even prefer it because I too can be an incredibly lazy programmer.
But I've been doing this shit for long enough now that most of TS's "benefits" feel lost on me. There are all these additional hoops to jump through to accomplish what I was already doing in vanilla JS. But I am not everyone. Everyone is not me. And I'll gladly admit that, for a great many people, TS might absolutely be the right tool for the job.
Thanks for taking the time to comment!!