As a founder/core engineer, it becomes paramount that you set the direction of your rocket-ship at the very start, because choosing an inefficient solution over time can compound negatively just as how a good decision can reap dividends in the long run.
Let’s talk about what TypeScript is first so we get the basics right.
In simple words, it’s a more supercharged version of JavaScript that is built to mitigate unforeseen bugs that could easily have been prevented.
As the name suggests, it’s a “typed” version of JavaScript. If you’ve done any frontend development at all, you’d know that vanilla JS is a dynamically-typed language, as in, we wouldn’t know what errors crop up because we chose to extract a property out of a supposed object that ended up being a “null” OR missing to pass a required prop into a React component causing it to crash leading up to an entire night of your team losing their marbles not knowing the origin of the bug with a customer on the verge of firing you.
It’s not that the developers are on the wrong here, but it’s the nature of JavaScript and to err is human. It’s very dynamic and flexible, but not always a good thing when it comes to building a robust, fail-proof application.
Enter TypeScript.
If you’re familiar with environments pertaining to Java, C, C++, you’d know that you’d have to specify explicitly what type a variable is going to assume when you define it, or define the properties of an object before beginning to utilise it. Should you ever deviate from the initial instructions later on, Java is going to shout at you and so would TypeScript, and that’s a good thing.
A few of the many positives that come out of using a strongly-typed language, especially TypeScript:
It mitigates bugs during compile time, thereby alerting your developers that something is remiss even before ever running the application on the browser, squashing 90% of those pesky bugs during development time.
TypeScript joining forces with a linter like ESLint forces you and your team to conform to best coding practices because you tend to thoroughly analyse how you’re going to structure your code before you write it, and not just type away (which leads to messy, unmaintainable code later on)
TypeScript provides just enough structure to satisfy static type advocates and just enough flexibility for dynamic type advocates. It’s the happy medium that will prevent your team from looking for something else.
CONCLUSION:
Even though learning to use TypeScript can be a bit of a learning curve and your development time might increase by 10–20% because you’re laying the foundation for every single component and function, the payoffs far exceed that of the downsides.
So now I’ll let you decide. Is it the end-all be-all for production-issues? Or is it an utter waste of man-hours?
What do you think? Do like and comment down below.
And Thanks for reading! :D
Top comments (2)
It might be because I come from a typed language background into JS rather than the other way around, but I find myself working faster in TS than Vanilla JS.
TypeScript is a typed superset of JavaScript that adds optional static typing and other features to improve developer productivity and code maintainability.