JavaScript & TypeScript

Both can hold any value, but they behave in opposite ways. any switches type checking off: you can call methods on it, pass it anywhere, and errors only appear at runtime. It also spreads, because whatever you derive from any is any too. unknown is the safe version: the compiler lets you store anything in it but refuses to let you use it until you narrow it with typeof, instanceof, a type predicate or a schema validation. I use unknown for JSON from the network, caught errors and third-party callbacks, and treat any as a code smell that needs a comment explaining why.

JavaScript runs on one thread with a call stack. Asynchronous work is delegated to the host (the browser or Node.js), and when it completes, a callback is queued. The event loop takes work from queues only when the stack is empty. Promise callbacks and await continuations go into the microtask queue; timers, I/O and UI events are macrotasks. After every macrotask, the engine drains the whole microtask queue before taking the next macrotask. So after the current script finishes, the resolved promise runs first, then the timer. The practical lesson: long synchronous work blocks everything, and an endless chain of microtasks can starve rendering.

Not directly. TypeScript is erased at build time, so the JavaScript that runs is the same as what you would write by hand, with no extra checks and no speed gain. The benefit is earlier feedback: a whole class of bugs (wrong property names, missing null handling, forgotten union cases, wrong argument order) is caught in the editor or CI instead of production. For real runtime safety at the edges, such as form input, API responses and environment variables, you still validate data with a schema library. The combination works best when the schema also produces the TypeScript type, so there is a single source of truth.

Generics are type parameters. They let a function, class or type work with many types while keeping the exact type information. Instead of a fetch helper that returns any, getJson<T> returns Promise<T>, so the caller gets a typed User or Order. Constraints like T extends { id: string } say what the type must at least contain, which lets the function safely read item.id. I reach for generics in reusable building blocks: API clients, repositories, form helpers, list components and state stores. If a function only ever handles one type, a generic adds noise and nothing else, so I don't use one there.

For object shapes they are nearly interchangeable, and consistency within a codebase matters more than the choice. Interfaces can be extended with extends and can be merged by declaring them twice, which is useful for augmenting library types such as a global Window or a framework's request object. Type aliases are more flexible: they can describe unions, tuples, mapped and conditional types, which interfaces cannot. My rule is simple: type aliases for unions and computed types, interfaces for public object contracts that others might extend. Whichever you choose, avoid mixing styles randomly, because reviewers then have to wonder whether the difference is intentional.

Gradually. First add a tsconfig with allowJs and checkJs off, so TypeScript compiles alongside the existing files without errors. Rename files to .ts one module at a time, starting with leaf utilities and the API layer, because types there flow into everything else. Turn on strict early for new files, even if old ones need temporary suppressions, and track the count of ts-expect-error comments so it only goes down. Add tsc --noEmit to CI immediately so new type errors cannot be merged. A post-edit check that reports only new errors against a baseline keeps the team moving without having to fix everything at once.

There are three main approaches, each with trade-offs. A shared TypeScript package in a monorepo is the simplest and gives instant feedback, but it couples release cycles and only works when every consumer is TypeScript. Generating types from a contract, such as an OpenAPI document or a GraphQL schema, works across languages and versions, at the cost of a codegen step and a contract that must be kept honest; I make CI fail if the generated output is out of date. End-to-end typed RPC like tRPC gives the best ergonomics but ties clients tightly to one server implementation. Whatever the choice, types alone are not enough at the network boundary: I still validate responses at runtime in one adapter layer, because a deployed backend and an old mobile client can disagree no matter what the compiler said.

For most application code I choose a union of string literals, or a const object with a derived union type when I also need the values at runtime, such as for a dropdown. Unions are erased completely, serialise naturally to JSON, narrow well in switches and work under erasableSyntaxOnly and Node's type stripping. TypeScript enums generate runtime objects, numeric enums accept any number, and const enums cause problems with isolated compilation, so they fit poorly in modern toolchains. The const object pattern gives the same benefits as an enum: autocomplete, a single source of values, iteration with Object.values, without the drawbacks. The one place enums still appear is older codebases, where consistency with existing code can matter more than the ideal choice.

Types describe shape, not behaviour or truth. They cannot prove a list is sorted, that an email really exists, that a price is non-negative, or that external data matches its declared type. They also have deliberate holes: casts, any, covariant arrays and unchecked index access. I design around this in layers. At boundaries, runtime schemas turn unknown input into trusted types. Inside the domain, branded types and smart constructors encode invariants such as positive amounts or validated ids, so invalid values cannot be created without passing a check. Discriminated unions make illegal states unrepresentable. Lint rules ban the escape hatches, or require a comment for them. Then tests cover what remains: business rules, ordering, timing and integration with real services.