TypeScript

TypeScript is JavaScript with a type checker standing in front of it. The types are erased before anything runs, so none of it exists at runtime: no checks, no coercion, no protection against a request body that turned up in the wrong shape. What you get instead is a compiler that reads the codebase the way an unusually patient reviewer would, and an editor that can tell you the fourteen places a renamed field breaks.

How we use it

It is the default for everything we build that is not PHP. Objectify runs it on both sides of the wire: the Worker that resolves an API key to a tenant shard, and the React dashboard that draws the schema designer over the same object model. In ClassProfile the payoff is sharper, because the monorepo holds the database schema in a shared package and both the Hono API and the browser client import their types from it. Renaming a profile column there breaks the build in the client, which is the cheapest place for it to break.

DMARC Engine parses hostile input for a living: MIME messages, zipped XML, X.509 certificates for BIMI. Types are the only documentation anyone will read for a parser like that. Starterflare derives most of its types from a 916 line Prisma schema, @Heartbeat and Jonosakti share types between a Next.js front end and a Worker backend, and 360nutri types the nutrition object the vision model is asked to return so the parsing code and the dashboard agree on what a meal is. Even Linked Corporate, eight static pages with no backend at all, is written in it, because on a Next.js project the marginal cost is nil.

What it costs you

It is a build step, and build steps rot. Type checking a monorepo is slow enough that people start skipping it locally and finding out in CI, and the fix is usually project references and incremental builds, which is another moving part to own.

The real cost is the boundary. A row out of D1, a JSON body, a response from someone else's API: all of it arrives untyped, and the usual move is to write as Thing and carry on. That cast is not a check, it is a comment the compiler agrees to believe. Every one of them is a place where the guarantee quietly stops, and they cluster exactly where the data is least trustworthy. Generated types drift too. Prisma and Drizzle output is only correct if someone regenerates it, and a schema migration applied without that step produces a codebase that compiles and lies.

Then there is version churn. The language ships every few months, its checks tighten, and library type definitions follow at their own pace. Coming back to a project after a year is rarely a one line upgrade, which is the subject of what dependency neglect actually costs. Retrofitting strict onto an existing project is worse: it is a week of honest work that produces no visible feature.

When we would choose something else

Types stop at the door, so anything crossing a trust boundary needs a real check at runtime rather than a declaration, and we reach for Zod and runtime validation there. A schema that both validates and infers its type is worth more than either half.

Where a project already lives in PHP we stay in PHP. Consonas is Laravel with typed properties and static analysis, and porting it to have a TypeScript backend would buy nothing but a rewrite, which is the argument set out on Laravel and PHP. For a genuinely small piece of glue, a scheduled Worker of fifty lines, plain JavaScript with a couple of JSDoc annotations is enough, and we do not add a compiler to a file nobody will edit twice.