EXPLAINER

TypeScript

TypeScript (TS) is JavaScript with a static type system. It compiles to plain JavaScript, catches a class of bugs in the editor, and is the default for SPFx, large React apps and many Node services.

Short answer: TypeScript (TS) is typed JavaScript. The compiler erases types and emits JS that Node or the browser runs. SPFx projects are TypeScript-first; see SharePoint Framework (SPFx). Application-level AI notes are in TypeScript for AI Applications.

What it is

TypeScript, abbreviated TS, is a language from Microsoft that adds static types to JavaScript. You write .ts or .tsx files. The compiler, tsc, checks types and emits ordinary JavaScript. Browsers and Node.js never run TypeScript itself. They run the emitted JS, or a tool such as Vite strips the types while bundling. If the types are wrong and you force the compile, the JS can still be wrong. Types are a check, not a sandbox.

This is the language behind SPFx projects and behind most serious React codebases. TypeScript for AI Applications talks about using it in AI applications. TypeScript Types for an API Client shows how to type an API client. This page is the language decision itself.

Why and when it is used

Use TypeScript when more than one person will touch the code, when the data has a shape (API responses, SPFx props, database rows), or when you want the editor to tell you that you renamed a field in only one place. The cost is a compile step and the discipline to not silence errors with any.

Plain JavaScript is enough for a tiny script. A gradual migration (allow JS files, add types at the edges) is often better than a big-bang rewrite. Do not adopt TypeScript and then turn strict off and cast everything to any. You paid the complexity and declined the benefit.

How it works

Types describe values: string, number, objects, unions (string | null), and generics that abstract over a type. The compiler uses structural typing: if two types have the same fields, they are compatible, even if their names differ. interface and type are both ways to name a shape. Strict null checks force you to handle undefined before you read a property. That one setting removes a whole class of production crashes.

At the boundary with the outside world (JSON from fetch, form input), the type system believes whatever you assert unless you parse. A type assertion (as User) is you telling the compiler to trust you. It is not validation. Pair it with a runtime check (How to Validate JSON) for data that crosses a process. Configuring tsconfig.json (strict, target, module) is part of the program, not paperwork.

Technologies and dependencies

Node or another JS runtime to execute output, the typescript package, and usually a bundler that understands TS. ESLint with the type-aware rules is worth it. Frameworks ship their own types (@types/... when the library is plain JS). SPFx pins a TypeScript version; forcing a newer compiler because a blog said so breaks the scaffold. npm installs all of this. Your tests run the JS behaviour; they do not replace the typecheck. Run both in CI.

How to get started

  1. Install Node, then npm install typescript in a project, not a global compiler you forget about.
  2. Run npx tsc --init and turn strict on before you have a thousand files.
  3. Type a function that takes a user object and returns a display name. Intentionally pass a number and read the error.
  4. Fetch JSON and write a function parseUser(data: unknown): User that checks the fields. Feel the difference between unknown and any.
  5. Add the typecheck to the same command you already run before commit.
  6. When a third-party type is wrong, patch it locally with a declaration merge or a thin wrapper. Do not any the entire module.

Read error messages from the first line. TypeScript errors pile up; the first mismatch is usually the real one.

Cautions and trade-offs

Types drift from runtime. A renamed API field will not throw at compile time if you typed the response by hand and then used a cast. Generate types from a schema or validate at runtime. any is contagious: one any parameter turns the return type into a shrug. enum compiles to real JS objects and surprises people who expected erasure; unions of string literals are often simpler.

Compile times grow with project size. Project references help later; they are not day-one work. SPFx and other scaffolds choose compiler versions for you; respect that. Finally, TypeScript will not design your module boundaries. A single types.ts of 2,000 lines is a design problem the compiler is happy to check forever.