The primary value-add that I have found with TypeScript is that its features add quality controls to your JavaScript project.
Is it necessary? No, but the value does become evident when an active project scales in complexity and age.
One of my active SaaS products is a Node.js app that started in 2012. Little/no tests, callback hell, and enough features to sell to the enterprise. When I was the team lead on that product’s mobile application, I would have to remediate bugs several times a year when a team member building features for the web modified a shared method and removed/modified an output. If we had types (or tests tbh) around the method’s I/O contract then it would have been caught before merge.
Additionally, callback hell paired with an architecture that IDE’s didn’t fully understand meant significantly more time mapping out process flows within the application. I had to do it a couple times when turnover left me as the one responsible; those efforts took several hours over multiple days, often repeating the exercise multiple times to validate the flow was accurate.
Today, I write all of my application source in TypeScript for new projects if I’m building a JavaScript runtime, but some things like Grunt.js are still authored as regular JavaScript
I am passionate about creation, be it code or written. I believe that knowledge should be sharee. If we all gave a little bit of our time to helping the each other, the world would be a better place.
The primary value-add that I have found with TypeScript is that its features add quality controls to your JavaScript project.
Is it necessary? No, but the value does become evident when an active project scales in complexity and age.
One of my active SaaS products is a Node.js app that started in 2012. Little/no tests, callback hell, and enough features to sell to the enterprise. When I was the team lead on that product’s mobile application, I would have to remediate bugs several times a year when a team member building features for the web modified a shared method and removed/modified an output. If we had types (or tests tbh) around the method’s I/O contract then it would have been caught before merge.
Additionally, callback hell paired with an architecture that IDE’s didn’t fully understand meant significantly more time mapping out process flows within the application. I had to do it a couple times when turnover left me as the one responsible; those efforts took several hours over multiple days, often repeating the exercise multiple times to validate the flow was accurate.
Today, I write all of my application source in TypeScript for new projects if I’m building a JavaScript runtime, but some things like Grunt.js are still authored as regular JavaScript
Thank you so much for explaining in this much detail. This kind of information is what I was looking for.
This question was shared on Twitter and some of the responses there were discouraging. If i was starting out,I would have given up on it entirely.