This guide is not itself the means to learn TypeScript. This guide addresses issues around getting started (obstacles, preliminary knowledge, etc.) and then points you to curated resources to start learning. Consider this material a prologue or an introduction to the learning process itself so, you have the needed background and context before beginning the learning process.<\/p>\n\n\n\n
The list below briefly highlights the knowledge needed before learning TypeScript:<\/p>\n\n\n\n
\"1\"+1<\/code> becomes 11<\/code> because JavaScript converts the number 1 to a string and then combines \"1\" + \"1\"<\/code>, which is \"11\"<\/code>. TypeScript aims to change\/eliminate both the dynamic and weakly typed nature of JavaScript just described.<\/li>\n\n\n\n- TypeScript is not one thing. TypeScript is a combination of the following three foundational things:\n
\n- TypeScript<\/strong> Type System:<\/strong> A syntax layered over the top of JavaScript for the purpose of making JavaScript a statically\/strongly typed language (aka \u201cTypeScript Types\u201d or \u201cTypeScript Type System\u201d).<\/li>\n\n\n\n
- TypeScript Compiler:<\/strong> A tool that both 1. interrupts (aka type checking) TypeScript syntax added to JavaScript as well as 2. converts TypeScript to JavaScript (aka the \u201cTypeScript Compiler\u201d or \u201ctsc\u201d). The compiler is provided as a Node.js npm package<\/a> which provides the \u201ctsc\u201d cli tool.<\/li>\n\n\n\n
- TypeScript<\/strong> Language Service:<\/strong> The TypeScript language service used by things like VSCode for analyzing TypeScript code as you type it (aka IntelliSens<\/a>e<\/a>, note that the compiler is separate from the language service<\/a>)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- TypeScript is incredibly popular amongst professional developers. If you want to be a professional web developer or Node.js developer, it will likely be the case today that you will need to know TypeScript.<\/li>\n\n\n\n
- TypeScript itself is not sent to a JavaScript runtime. TypeScript must be converted or built by a compiler to standard ECMAScript before it can be run by a JavaScript engine within a host environment (e.g., web browsers and Node.js). The job of transforming TypeScript to JavaScript is handled by the TypeScript compiler.<\/li>\n\n\n\n
- Anything that is standard JavaScript is valid TypeScript (i.e., TypeScript is a superset of JavaScript). When you are writing TypeScript-specific syntax (e.g., Type Annotations) you are using syntax that is not standard JavaScript (i.e., not in the ECMAScript specification). While TypeScript can be converted to valid JavaScript, TypeScript itself is not valid JavaScript. If a JavaScript runtime executes TypeScript, it will produce a runtime error because, again, TypeScript is not valid JavaScript.<\/li>\n\n\n\n
- TypeScript promises that it will never change the behavior of your program; it will only ever remove itself from your JavaScript.<\/li>\n\n\n\n
- One should consider that adopting TypeScript is signing on to a subjective and stricter layer of control beyond JavaScript standards. This means that TypeScript requires not only valid JavaScript but also valid TypeScript. In this sense, TypeScript is another layer of control guiding how one should write JavaScript (e.g., TypeScript aims to change the fact that JavaScript has dynamic types and is weakly typed). When Typescript is not valid, you get an error in addition to the potential errors that come from invalid JavaScript.<\/li>\n\n\n\n
- TypeScript is currently in a class of its own. Flow was a similar solution from the past, but it is less popular today. Most developers seeking to write JavaScript and use type annotations use TypeScript. The alternative to solutions like TypeScript and Flow entails abandoning JavaScript for a custom language with a built-in type system that compiles to JavaScript (e.g., Elm, PureScript, ClojureScript, etc.). Compared to languages with built-in type systems, TypeScript is a bolted-on solution to JavaScript, not a new language itself.<\/li>\n\n\n\n
- TypeScript can also be used to compile today\u2019s ECMAScript to older versions of ECMAScript (e.g., ES 2023 to EE5). This aspect of TypeScript overlaps with tools like Babel<\/a>, SWC<\/a>, esbuild<\/a>, and Surcase<\/a>. Note that it\u2019s possible to use TypeScript for its type engine and then hand off compiling to tools like Babel<\/a>, SWC<\/a>, esbuild<\/a>, and Surcase<\/a> or use TypeScript alone for both ECMAScript conversion and its type-checking engine.<\/li>\n\n\n\n
- Similar to Babel<\/a>, SWC<\/a>, esbuild<\/a>, and Surcase<\/a>, TypeScript can compile JavaScript from staged ECMAScript proposals<\/a> that have not yet been officially added to ECMAScript (i.e. make use of JavaScript code before it becomes part of JavaScript). This allows you to use new futuristic non-standard changes to the ECMAScript language today.<\/li>\n\n\n\n
- JavaScript files are typically named with a file extension of \u201c.js\u201d. TypeScript files are typically named with a file extension of \u201c.ts\u201d. If you are using JSX in \u201c.ts\u201d files, these files will have the file extension \u201c.tsx\u201d.<\/li>\n\n\n\n
- While not necessarily true in the past, as of today TypeScript aims to be compliant with the direction of ECMAScript. Setting aside type annotations, today TypeScript does not try and introduce non-standard JavaScript syntax that has zero paths to potentially being adopted by JavaScript.<\/li>\n<\/ul>\n\n\n\n
Why Learn\/Use TypeScript?<\/h2>\n\n\n\n
Today, most developers who professionally use JavaScript to build software use TypeScript. They do so for the following reasons: By learning TypeScript and learning it well, you\u2019ll better understand the complicated parts of JavaScript, which will make you a better JavaScript developer.<\/p>\n\n\n\n
\n- It is not uncommon that employers today require or prefer the use of TypeScript to maintain large repositories of JavaScript code. (i.e., to compete in the job market today, you need TypeScript knowledge).<\/li>\n\n\n\n
- By using a strongly typed version of JavaScript with clearly defined guard rails, larger teams can enforce strict coding practices that can safeguard the code against less experienced developers.<\/li>\n\n\n\n
- The authoring experience through tooling is a superior experience to authoring plain JavaScript. (e.g., VS Code offers an enhanced developer experience when using TypeScript<\/a>).<\/li>\n<\/ul>\n\n\n\n
Getting Started with TypeScript Obstacles<\/h2>\n\n\n\nSteep Learning Curve<\/h3>\n\n\n\n
Adding on TypeScript can be extremely overwhelming both academically and in practice. This is especially true for those just learning JavaScript as well as those who are seasoned JavaScript developers.<\/p>\n\n\n\n
More Rules, More Errors<\/h3>\n\n\n\n
TypeScript adds additional rules to the JavaScript language regarding data types and will throw a TypeScript error when JavaScript does not. This can be a bit confusing and frustrating. It can\u2019t be stated enough that TypeScript is bossy and a bit messy, especially if TypeScript expects that all values avoid the any<\/code><\/a> type.<\/p>\n\n\n\nMore Code, More Development Time\/Management<\/h3>\n\n\n\n
TypeScript type annotations are nonstandard syntactical overhead. It adds more lines of code to your files (i.e., type annotations) and more files (i.e., type declarations) to your code base. It is simply more information to take in and manage. Given a large code base authored and maintained by developers of differing skills, this may be ideal. But it does have a cost. Grokking TypeScript and TypeScript annotations and appeasing the TypeScript compiler can be frustrating, daunting, and time-consuming.<\/p>\n\n\n\n
The fact is, that TypeScript takes more time and adds lines of complexity. Many teams believe the value provided to be worth the overhead. The cost of implementation vs. the value provided is a complicated equation with many variables. How developers evaluate this equation often will say more about the developers than it says objectively about code quality, code durability, or code longevity.<\/p>\n\n\n\n
A Compiler Step<\/h3>\n\n\n\n
While most professionals are already accustomed to the tooling\/building processes that modern JavaScript development requires TypeScript is a far cry from simply writing some code that is executed by a web browser by way of a script element. TypeScript comes with the overhead of compiling it to standard JavaScript.<\/p>\n\n\n\n
Top Use Cases of TypeScript<\/h2>\n\n\n\n
The following four use cases for TypeScript overlap and extend the reasons why a developer might choose to learn TypeScript:<\/p>\n\n\n\n
\n- Typescripts Type System Brings Strongly Typed Enforceable Mechanics to JavaScript<\/a><\/strong><\/li>\n\n\n\n
- TypeScript Reports JavaScript Syntax Errors as well as TypeScript Type Errors<\/a><\/strong><\/li>\n\n\n\n
- TypeScript & VS Code Provide a Superior Authoring Environment for JavaScript<\/a><\/strong><\/li>\n\n\n\n
- TypeScript Can Compile Current and Next Generation ECMAScript to Older ECMAScript<\/a><\/strong><\/li>\n<\/ul>\n\n\n\n
Let\u2019s examine each of these use cases in more detail.<\/p>\n\n\n\n
Typescripts Type System Brings Strongly Typed Enforceable Mechanics to JavaScript<\/h3>\n\n\n\n
TypeScript is most well-known for its type system. I\u2019ll briefly explain the tenants and implications of this system so that one can minimally begin to understand its value.<\/p>\n\n\n\n
To review, the JavaScript language has eight types of values that can be used by the language<\/a>:<\/p>\n\n\n\n\nBoolean<\/code><\/li>\n\n\n\nnull<\/code><\/li>\n\n\n\nundefined<\/code><\/li>\n\n\n\nNumber<\/code><\/li>\n\n\n\nBigInt<\/code><\/li>\n\n\n\nString<\/code><\/li>\n\n\n\nSymbol<\/code><\/li>\n\n\n\nObject<\/code><\/li>\n<\/ol>\n\n\n\nBehind the scenes, JavaScript dynamically assigns one of these types to JavaScript values and will transparently allow reassignment and coercion<\/a> of these types. TypeScript\u2019s main objective is to change this aspect of JavaScript.<\/p>\n\n\n\nIn the code example below, I\u2019m using several JavaScript data types (i.e., Strings, Objects, and a Number):<\/p>\n\n\n
let<\/span> firstName = \"Sally\"<\/span>;\nlet<\/span> lastName = \"Brown\"<\/span>;\nlet<\/span> age = 25<\/span>;\n\nlet<\/span> user1 = {\n firstName: \"Bill\"<\/span>,\n lastName: \"Fae\"<\/span>,\n age: 45<\/span>,\n};\n\nconst<\/span> getFullName = (user1<\/span><\/span>) =><\/span> {\n return<\/span> `${user.firstName}<\/span> ${user.lastName}<\/span>`<\/span>;\n};\n\nconsole<\/span>.log(getFullName(user)); \/\/ logs \"Bill Fae\"<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\nWithout TypeScript, JavaScript would have no problem if we decided to change the value of age from a number to a string. Or if we decided to change the shape of the user object by adding a new property to the user Object called middleName. JavaScript would also be ok if we passed the getFullName() function an empty object, until the code is run.<\/p>\n\n\n\n
However, by using TypeScript and its type system, we can add type annotations to JavaScript that will make JavaScript act more like a programming language that does not allow type reassignment, changes, and JavaScript runtime errors.<\/p>\n\n\n\n
Below I am taking the previous code and adding all possible TypeScript type annotations to the JavaScript. You should carefully contrast this code to the previous code with no type annotations.<\/p>\n\n\n
let<\/span> firstName: string<\/span> = \"Sally\"<\/span>;\nlet<\/span> lastName: string<\/span> = \"Brown\"<\/span>;\nlet<\/span> age: number<\/span> = 25<\/span>;\n\n\/\/ define the shape of a user object before defining a user object<\/span>\ninterface<\/span> UserTypeInterface {\n firstName: string<\/span>;\n lastName: string<\/span>;\n age: number<\/span>;\n}\n\n\/\/ define a user, annotate user with a type interface<\/span>\nlet<\/span> user1: UserTypeInterface = {\n firstName: \"Bill\"<\/span>,\n lastName: \"Fae\"<\/span>,\n age: 45<\/span>,\n};\n\n\/\/ create a function, that only accepts values matching our UserTypeInterface,<\/span>\n\/\/ also, define what should be returned from this function<\/span>\nconst<\/span> getFullName = (user1: UserTypeInterface): string<\/span> =><\/span> {\n return<\/span> `${user.firstName}<\/span> ${user.lastName}<\/span>`<\/span>;\n};\n\nconsole<\/span>.log(getFullName(user)); \/\/ logs \"Bill Fae\"<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\nBy using TypeScript type annotations, we have layered a degree of control over our JavaScript, which enforces patterns from strongly typed languages. For example,<\/a> I can no longer change the type of value that age can contain, or the shape of the user object, or create a function that will accept any type of value. What JavaScript would permit in our program is not permitted when using TypeScript. In the video below you will see that TypeScript reports issues where JavaScript does not.<\/p>\n\n\n\n\t\t\n\t\t\t