This is the first part in a series of tutorials on getting started with TypeScript in a Node.js setting. Part 1 explains the motivation why these tools are used.
Node.js also comes bundled with npm, a package manager that lets you easily download and use libraries made by other people. npm is the largest repository of open-source software in the world, and libraries exist for any functionality you can think of.
For these reasons (and others I won’t go into), Node.js is a great choice when you are making an API that other applications will connect to, such as providing a back-end service for a mobile app. Node.js also has capabilities for real-time communications through WebSockets, making it very simple to implement real-time functionality for your app, such as chat, games, or any other interactive experience.
obj.propertyname when what you wanted was
obj.propertyName, and not finding out about the error until the program has been running for quite some time.
Because you can’t really know if a piece of code works or not until you execute it, programmers have come up with a huge number of testing methodologies and frameworks to ensure that the code they wrote actually does what they think. However, instead of testing out the code by running it, it is possible to run a program that checks the code for the use of missing properties, mismatched types, and proper arguments and return values of functions. This program can warn the programmer ahead of time of errors in their code, which would allow them to fix the errors without actually having to run the code. In essence, it answers the question “Do the components of my program actually fit together?”. This is where TypeScript comes in.
var myStr = "foo"; var myNum = 15; myStr = myNum; //JS will happily accept this console.log(myStr.length); //will output undefined /* length gives us the number of characters on a string, but myStr is now a number! This code is valid JS, and the length of myStr is now undefined. If we were expecting the length to exist down the line, an undefined length would potentially lead to major errors. */
Contrast this with TypeScript:
var myStr:string = "foo"; //myStr is of type string var myNum:number = 15; //myNum is of type number myStr = myNum; console.log(myStr.length); //will never get here /* TS will throw a compile-time error at line 3, letting the programmer know that it is not possible to assign a number to a string. */
As we can see from this example, TypeScript will not be allow this code to be compiled and will give the programmer the location of the error. This will allow the programmer to either fix a potential error, or force them to make their meaning unambiguous and clear (for example, if they wanted to assign the string representation of the number 15 to the variable myStr, they must use
myNum.toString()). I find this feature greatly useful, since it gives me the piece of mind that my code is properly typed, whereas with plain JS for the most part, I did not even have that. Also, when the time comes to make changes to my classes or interfaces, all my existing code will fail to compile, forcing me to recheck all the uses of my classes and reevaluate the validity of my changes.
What is the cost of using TypeScript?
Part 2 will focus on setting up the tools and structure that will enable the creation, maintenance, and expansion of a project all the way to large codebases.