What Is TypeScript and How Do You Use It?

Understand what TypeScript is, how it relates to JavaScript, the tradeoffs it brings, and the practical workflow — tsc, tsconfig.json, and editor tooling — you'll use throughout this course.

Before writing a single type annotation, it helps to know exactly what TypeScript is doing for you, where it runs, and what tools turn your .ts files into JavaScript a browser or Node.js can actually execute.

TypeScript as a Superset of JavaScript

TypeScript is a strict syntactic superset of JavaScript, developed and maintained by Microsoft. 'Superset' means every valid JavaScript program is also valid TypeScript — you can rename any .js file to .ts and it will still work — but TypeScript adds an optional layer of static types on top: annotations like : string or : number[] that describe the shape of your data. TypeScript never invents new runtime behavior; it is purely a development-time layer that gets erased when your code is compiled to JavaScript.

'Static type checking' means TypeScript verifies your code's types while you're writing it — before it ever runs — as opposed to JavaScript, which is dynamically typed and only discovers type mismatches at runtime (often as a crash in production). This is the core distinction between compile time (when TypeScript analyzes your code and reports errors) and runtime (when the compiled JavaScript actually executes) — a TypeScript error can exist purely at compile time and never appear as a runtime Error object at all.

The benefits are substantial: TypeScript catches typos and mismatched data shapes before deployment, makes large codebases dramatically easier to navigate (autocomplete knows exactly what properties an object has), and effectively serves as always-up-to-date documentation of function contracts. The tradeoffs are real too: there's a learning curve, an extra compile step in your workflow, and it's possible to write low-value, over-engineered types that slow a team down rather than help it — good TypeScript is written pragmatically, not maximally.

• Superset: all valid JavaScript is valid TypeScript. • Static typing: errors caught while writing code, not just while running it. • Compile time = when tsc analyzes/checks your code; runtime = when the resulting JS actually executes. • Benefit: autocomplete, refactor safety, self-documenting function signatures. • Limitation: extra build step, a real learning curve, and the risk of over-typing simple code.

The TypeScript Workflow: From .ts to Running Code

TypeScript code doesn't run directly in a browser or in Node.js — it has to be compiled (also called 'transpiled') into plain JavaScript first. The TypeScript compiler, invoked from the command line as tsc, reads your .ts files, checks them for type errors, and — if there are no blocking errors — emits corresponding .js files with all the type annotations stripped away. tsc is itself distributed as an npm package, which means you need Node.js (the JavaScript runtime) and npm (Node's package manager, used to install tsc and other dependencies) installed before you can use it.

A tsconfig.json file at the root of a project tells tsc how to behave: which files to include, which JavaScript version to target, how strict the type checking should be (the strict flag turns on a whole family of safety checks and is strongly recommended for every real project), and where to put the compiled output. Running tsc --init generates a starter tsconfig.json with sensible commented-out defaults you can uncomment as needed.

For quick experiments without installing anything, the TypeScript Playground (a website run by the TypeScript team) lets you type TypeScript in a browser and see both the compiled JavaScript output and any type errors instantly — it's an excellent way to test a snippet or share a reproducible example. For day-to-day project work, VS Code (also made by Microsoft) has TypeScript support built in natively: it type-checks your file live, underlines errors in red as you type, and gives rich autocomplete — no extension required.

• Node.js = the JavaScript runtime that lets you run tsc (and JavaScript) outside a browser. • npm = Node's package manager, used to install typescript and other libraries. • tsc = the TypeScript compiler; tsc file.ts compiles a single file, tsc alone uses tsconfig.json. • tsconfig.json = project-wide compiler configuration (strictness, target JS version, output folder). • TypeScript Playground = browser-based sandbox for trying TypeScript with zero setup. • VS Code = has TypeScript checking and autocomplete built in out of the box.

Your first TypeScript file

Notice the : string annotation is present in the .ts source but completely gone from the compiled .js — types are a compile-time-only concept. If you wrote const name: string = 42; instead, tsc would refuse to compile cleanly and report a type error.

// hello.ts
const name: string = "SampleApp";
console.log(name);

// compile it:
//   tsc hello.ts
// this produces hello.js:
//   const name = "SampleApp";
//   console.log(name);
// run the JavaScript output with Node:
//   node hello.js

Code Examples

This is the entire value proposition of TypeScript in one example: the mismatch between the declared type (string) and the assigned value (42, a number) is caught the moment you compile — not later when some other part of the program tries to call a string method on it and crashes at runtime. Expected result: SampleApp

Common mistake: Forgetting to actually run tsc (or having your editor's error underline ignored) means you can still accidentally run outdated or broken JavaScript — always treat a red squiggly line as a build-blocking error, not a suggestion.

target picks which JavaScript version the compiled output uses, strict turns on TypeScript's full suite of safety checks (highly recommended for every project in this course), and outDir/rootDir keep your compiled .js files separate from your source .ts files so they don't get mixed together. Running tsc with no arguments in a folder containing this file compiles every .ts file under src/ into matching .js files under dist/.

const name: string = "SampleApp";
console.log(name);

// try changing the line above to:
// const name: string = 42;
// tsc will report:
// error TS2322: Type 'number' is not assignable to type 'string'.

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "strict": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"]
}

The TypeScript compile pipeline

TypeScript only exists between 'you write' and 'plain JavaScript' — by the time code reaches the runtime, every type annotation has already been stripped away.

you write          type-checked by          plain JavaScript          runs in
hello.ts   ---->      tsc (using       ---->     hello.js       ---->   Node.js /
(typed)              tsconfig.json)              (untyped)               Browser

Important Rules

TypeScript never changes what your code does at runtime — it only checks it before that point.

Always compile (or let your build tool compile) before assuming code is correct; a red editor squiggle means the build will fail.

Enable strict: true in tsconfig.json for new projects — it's the single highest-value setting in the whole file.

Use the Playground for quick one-off questions; use a real project with tsconfig.json for anything you're keeping.

Where this shows up

Virtually every production React application on EngiLipi's own tech stack, and across the industry, is written in TypeScript with a tsconfig.json at the project root and strict mode enabled — knowing this pipeline (edit → tsc type-checks → JavaScript emitted → runtime executes) is exactly what happens every time you save a file in a real TypeScript project, whether that compile step is triggered manually or by a bundler like Vite or webpack.

Renaming a .js file to .ts and assuming it is now fully type-safe

Gradually adding explicit types and enabling strict mode, then fixing the errors it reveals

A renamed file compiles because TypeScript is a JavaScript superset, but without annotations and strict mode most values are implicitly any, so you get almost none of TypeScript's actual safety benefits until you add real types.

[multiple-choice] What does it mean that TypeScript is a 'superset' of JavaScript? A. TypeScript replaces JavaScript entirely at runtime B. Every valid JavaScript program is also valid TypeScript, with types added on top C. TypeScript can only be used with React D. TypeScript and JavaScript are unrelated languages that happen to look similar

B. Every valid JavaScript program is also valid TypeScript, with types added on top — A superset means TypeScript includes all of JavaScript's syntax plus additional features (like type annotations) — any .js file can be renamed to .ts and will still be valid.

[multiple-choice] Which command-line tool actually type-checks and compiles TypeScript into JavaScript? A. npm B. node C. tsc D. git

C. tsc — tsc is the TypeScript compiler. npm manages packages, node runs JavaScript, and git is unrelated version control.

[predict-output] Given const name: string = 42;, what happens when you run tsc on the file? A. It compiles fine and logs 42 B. It reports a compile-time type error and does not emit valid output as expected C. It silently converts 42 to "42" D. It only fails when the JavaScript is executed, not when compiled

B. It reports a compile-time type error and does not emit valid output as expected — Assigning a number to a variable explicitly typed as string is a type mismatch that TypeScript catches at compile time, before the code ever runs.

Install TypeScript locally with npm (npm install -g typescript or as a project dependency), create a file greet.ts with a typed const string and a console.log, then run tsc greet.ts and inspect the generated greet.js. Next, deliberately introduce a type mismatch and observe the compiler error.

// greet.ts const greeting: string = "Hello, TypeScript!"; console.log(greeting); // terminal: // npm install -g typescript // tsc greet.ts // node greet.js -> Hello, TypeScript!

After installing, run tsc --version to confirm it's available, then tsc greet.ts followed by node greet.js to see the JavaScript actually execute.