Glossary

TypeScript

TypeScript helps reveal an incorrect assumption about the shape of data or an API before it reaches the browser. It is not a runtime validator, security layer or replacement for tests.

Short definition

Types check the source code; the result remains JavaScript.

TypeScript understands JavaScript syntax and adds annotations, inference, interfaces, generics and value compatibility checks. The tsc compiler can check types and, depending on its configuration, output JavaScript or act only as a checker. JavaScript projects commonly run it through npm with Node.js as the tooling runtime, often as part of a build. The same system gives editors navigation, refactoring and faster discovery of invalid calls.

Type information is erased during compilation. If an API returns unexpected JSON, TypeScript cannot prevent it merely because a variable has a declared type. Untrusted data boundaries need runtime validation, correct error states and server-side authorization. TypeScript improves the design and maintenance of client code, not the trustworthiness of its input.

What it is used for

More precise contracts in frontend and integration code

Its greatest value appears with shared data models, larger components and frequent API changes.

  • types for requests, responses and component states when calling an HTTP API
  • refactoring modules while detecting invalid arguments and return values
  • generic helper functions for lists, forms and loading results
  • clearer handling of null, optional values and union states
  • checks in CI alongside tests, linting and the frontend application build

Practical example

Modelling the state of an availability request

A union type expresses that a component cannot simultaneously be in loading, error and ready states. When another state is added, the compiler can identify places where the code fails to handle every variant. This is more precise than several independent Boolean flags that can form a contradictory combination.

The example describes state inside the application. Before an API response is converted to this type, it must be validated in practice because network input can be corrupted, outdated or obtained from another backend version.

TypeScript

type Availability =
  | { state: 'loading' }
  | { state: 'ready'; inStock: boolean }
  | { state: 'error'; message: string };

function label(value: Availability): string {
  return value.state === 'ready' && value.inStock ? 'Skladem' : 'Ověřuji dostupnost';
}

How it works

From TypeScript source to checked JavaScript

Type checking happens before the program runs and must match how the JavaScript will actually be loaded and executed.

  1. The source describes values The developer adds types where they improve the contract; the compiler infers others from usage and declarations.
  2. tsconfig defines the rules The configuration sets strictness, modules, the target JavaScript and emission behaviour. It must match the bundler or runtime.
  3. The compiler checks relationships It detects property typos, invalid arguments, missing union variants and incorrect return values, for example.
  4. Types are removed The output contains JavaScript. The browser and Node.js do not perform TypeScript checks for every request.
  5. The runtime validates external data API responses, URL parameters and local storage are validated at the boundary; the rest of the program can then work with them through a safe type.

Important concepts and synonyms

Type checking before execution, not a new runtime.

TypeScript is often described as a typed superset of JavaScript; it is more precise to emphasise its static checks and erased types.

Inference and annotations

The compiler infers many types from values and usage. An annotation is useful at a public function or model boundary but unnecessary for every local variable.

Unions and narrowing

A union says a value can have several forms. A condition on a discriminating property narrows the possible variant and supports safer state processing.

interface and type

Both can describe a value shape. The choice depends on extension and type composition needs; neither creates a runtime object or validator.

Generics

A generic type preserves information about a value type in a reusable function or data structure. It should not be an abstraction without a concrete benefit.

strict and any

Strict mode tightens selected checks. any instead disables part of the checking; it may be necessary during migration, but as a permanent escape hatch it reduces the value of TypeScript.

Benefits and limitations

A more precise contract brings discipline, not absolute certainty.

Benefits

  • property, argument and return-value errors are caught before execution
  • safer refactoring of modules and shared data models
  • better navigation, autocomplete and usage search in the editor
  • explicit modelling of loading, error and success states

Risks and common mistakes

  • using a type assertion or any to silence a genuine problem
  • assuming an API response has the declared type without runtime validation
  • overly complex generics that make the interface unreadable
  • module and emit configuration that does not match the bundler or runtime
  • treating a green tsc result as a replacement for tests, security checks and code review

When it provides the most value

As frontend boundaries and shared contracts grow.

TypeScript is particularly helpful in an application with multiple modules, more complex forms, API data and long-term maintenance. Plain, well-structured JavaScript may be more proportionate for a small isolated script. The choice depends on the lifetime of the code, frequency of changes and whether the team genuinely maintains the configuration and types.

Migration need not happen all at once. A team can begin at API boundaries and in new modules, enable reasonably strict checks and gradually reduce places using any. The goal is not to add types for their own sake but to catch errors where they provide real value.

What to consider

Trustworthy types begin at the data boundary.

TypeScript is most effective when imprecise input is isolated and the rest of the code works with clear states.

  • enable a reasonably strict tsconfig and run type checking in CI
  • model loading, error and success for API responses instead of using loose Boolean flags
  • do not use any or as as an automatic solution to compiler errors
  • validate network data, URL parameters and stored values before treating them as trusted
  • verify that TypeScript module and emit settings match the real bundler or runtime

Common questions

TypeScript in practice

Is TypeScript a new runtime that replaces JavaScript?

No. TypeScript is checked before execution and its type notation is removed. The browser normally executes the resulting JavaScript.

Does TypeScript replace runtime API validation?

No. A network response may have a different shape from the declared type. The actual data needs to be validated and failures handled at the API boundary.

Do I have to type every variable?

No. The compiler infers many types correctly. An annotation provides the most value at a public interface, complex model or wherever it clarifies intent.

Are interface and type the same thing?

Both can describe value shapes but differ in composition and extension options. A clear contract matters more in ordinary code than a dogmatic choice.

How I build applications in practice

I handle data contracts from the API boundary through to the user interface.

For e-commerce and integration applications, I connect frontend states with APIs, validation, testing and a clear data architecture.

Request a call

I will call you on the next working day between 9:00 and 17:00.

You can also call me directly.

+420 605 181 728

Leave your phone number and send a callback request.

By sending, you agree to processing your data in order to handle your request.