TypeScript
Why I Reach for TypeScript on Every Project
By Vivek Jalondhara · 2 min read
Published May 2026 · Updated
Types aren't bureaucracy — they're the cheapest documentation and the fastest feedback loop you can buy.
Every project I start gets TypeScript on day one. The reason is simple: types are the cheapest documentation you'll ever write, and they pay you back every single time you refactor. When a function signature changes, the compiler tells me every call site that needs attention — no grepping, no guessing.
The bigger win is at module boundaries. DTOs, API responses, and config objects are where bugs hide, and a well-typed contract turns a runtime surprise into a red squiggle in your editor. I lean on discriminated unions and `zod`/`yup` at the edges so external data is validated once and trusted everywhere after.
TypeScript isn't free — generics and conditional types can get baroque. My rule: optimize for the reader. If a type needs a PhD to understand, I simplify the code until the type is obvious. Clarity beats cleverness.
Represent booking outcomes explicitly
A booking interface has more than a success state. A discriminated union makes the unavailable-slot path visible to the caller, instead of returning a reservation-shaped object with missing fields.
Illustrative example · TypeScript · Simplified for explanation
type BookingResult =
| { status: "confirmed"; reservationId: string }
| { status: "unavailable"; alternatives: string[] };
function message(result: BookingResult) {
return result.status === "confirmed"
? `Booked: ${result.reservationId}`
: "That slot is no longer available.";
}- Booking request
- Validated response
- Confirmed or unavailable UI
Conceptual flow for the example above.
Tradeoff to keep in mind
Types help after runtime validation. An HTTP response is still untrusted input; a type assertion does not validate it.