Update intro-and-motivation.md

CharlieDigital · web-flow · commit f4d0a7671d8d · 2025-03-18T07:45:40.000-04:00
diff --git a/docs/pages/intro-and-motivation.md b/docs/pages/intro-and-motivation.md
@@ -363,6 +363,7 @@ export class CreateOrganizationAttributeInput {
   readonly enabled?: boolean;
 }
 ```
+A common theme in TypeScript is that teams end up creating a lot of ancillary models that describe their *actual models* because despite the richness and flexibilty of the TypeScript type system, the underlying JavaScript type system at runtime isn't rich enough and there's not enough type metadata available on the domain models by themselves (thus a secondary validation schema for soemthing as simple as "this should be an integer").  This becomes apparent when looking at [ORMs in TypeScript versus C#](./intermediate/databases-and-orms.md) which again requires a schema to produce a domain model or falls back on strings.
 
 Without the basic facilities for effective runtime type checking, JavaScript at runtime is entirely dependent on *extra work* to inform the runtime about type metadata.  Another example of this is [Cal.com's `event-types.ts` zod schemas](https://github.com/calcom/cal.com/blob/main/apps/api/v1/lib/validations/event-type.ts) which shows a different pattern using Zod schemas (this being their V1 API versus the previous V2 API example above):
 

Original file line number	Diff line number	Diff line change
`@@ -363,6 +363,7 @@ export class CreateOrganizationAttributeInput {`
`363`	`363`	`readonly enabled?: boolean;`
`364`	`364`	`}`
`365`	`365`	```
	`366`	+A common theme in TypeScript is that teams end up creating a lot of ancillary models that describe their actual models because despite the richness and flexibilty of the TypeScript type system, the underlying JavaScript type system at runtime isn't rich enough and there's not enough type metadata available on the domain models by themselves (thus a secondary validation schema for soemthing as simple as "this should be an integer"). This becomes apparent when looking at [ORMs in TypeScript versus C#](./intermediate/databases-and-orms.md) which again requires a schema to produce a domain model or falls back on strings.
`366`	`367`
`367`	`368`	Without the basic facilities for effective runtime type checking, JavaScript at runtime is entirely dependent on extra work to inform the runtime about type metadata. Another example of this is [Cal.com's `event-types.ts` zod schemas](https://github.com/calcom/cal.com/blob/main/apps/api/v1/lib/validations/event-type.ts) which shows a different pattern using Zod schemas (this being their V1 API versus the previous V2 API example above):
`368`	`369`