Type-Driven vs Object-Driven Development

TypeScript comes in many flavors. Some developers love it, some hate it, and others simply dislike that it’s JavaScript wearing a strange mask. I’ve seen firsthand how frustrated JavaScript-only developers can become when they encounter type errors. Because TypeScript’s learning curve can feel unpredictable and odd, it often creates a noticeable knowledge gap in a codebase. Some people learn just enough to cast everything to any in order to dodge the hassles, while others go all in on fully typed projects that are beautifully precise but can be tough to maintain. Then there’s the middle ground: those who know enough TypeScript to avoid as any but still write code in a practical, human-friendly way. No matter where you fall on that spectrum, if you have even a little familiarity with TypeScript, you’ve likely formed an opinion - consciously or otherwise - on how to define entities. That’s what this article is all about. Different organizations, open-source projects, and libraries adopt various methods for defining entities. We’ll explore several approaches and, most importantly, discuss their pros and cons.

Building a Social Network

To avoid the usual car-and-plane comparisons, let’s define entities for a fictional social network called NotMySpace. In the codebase for this social network, we have these entities:

1. Organization - A document containing an image, name, and year of creation for an organization.
2. User - A document holding metadata about a user, including their password hash. Users are typically invited to organizations, and when added, they are placed in the organization->users array.
3. Session - A document created when a user logs in on any device. It contains a generated access token and a TTL (time to live) value.

Depending on your use case, the libraries you rely on, and your level of experience, you might choose to define these entities as types first, or as schemas first. Let’s examine these approaches:

Object-Driven Development

Imagine you’re defining the User entity. You might use a library like Zod, which follows an object-driven development approach. You specify an object at runtime (the Zod schema), and then infer the type from that object: // Abstract code const UserSchema = z .object({ email: z.string().min(4), passwordHash: z.string(), image: z.string().url(), }); type User = z.infer<typeof UserSchema> Here, UserSchema is a Zod schema instance that comes with its own methods - such as parse or safeParse - which you can use to validate any object against the schema. Meanwhile, User is simply the inferred TypeScript type, which can be used for function arguments, return values, class properties, etc. This exemplifies “object-driven development” because you define the runtime object first and then derive the TypeScript type from it.

Pros of Object-Driven Development

• Runtime-first: In most cases it's much easier to think about potential schemas and solutions for entity instances when represented as classes/inline objects.
• Documentation: The schema itself can act as documentation, making it clear what your data should look like and what default values may be specified.

Cons of Object-Driven Development

• Mixed approach risk: If you define some entities as schemas but directly type others (particularly “throwaway” or transient objects), your codebase can become inconsistent and harder to maintain.
• Added overhead: Schemas bring additional runtime checks, which can be unnecessary for simple or internal data structures that don’t need validation.
• More verbose: You’re writing more code - both the schema and the inferred type - just to define a single entity. While some cases it will pay off, it is not as straightforward as defining a type right away.

Type-Driven Development

On the flip side, you can define your types right away, before writing any runtime code. This strategy lets you think through your data models in a purely static way. Once you have your types, you can start building the logic around them. For instance: export interface User { email: string passwordHash: string image: string }; export interface Organization { name: string image: string yearCreated: number users: User[] }; export interface Session { accessToken: string ttl: number userId: string }; You might then generate or write runtime validation code only when you need it - if you need it at all.

Pros of Type-Driven Development

• Simplicity: You define everything in TypeScript types, which stay purely in the compilation layer. There’s no additional runtime overhead unless you choose to add it.
• Clarity in code organization: All your types can be grouped in a dedicated folder or package, making them easy to maintain. You are not tied to a specific library toolchain, nor are forced to parse runtime code in order to obtain the type.
• Great for short-lived data structures: If you’re dealing with short-lived objects (e.g., data that doesn’t need full-blown validation), it’s simpler to define them as types without worrying about runtime schemas.

Cons of Type-Driven Development

• Potential duplication: Libraries like Joi and Zod may force you to re-define the schema in object form anyways. While Joi allows you to pass in a type generic, Zod doesn't, which means that you will be forced to "mirror" your type definitions. Ultimately, using Zod means that you will most likely mix Object-Driven and Type-Driven approaches - which is not always ideal.
• Easier to ignore best practices: Since TypeScript won’t enforce correct usage at runtime, you could inadvertently rely on invalid data.

Choosing the Right Approach (or Blending Them)

Which approach is better? As I mentioned earlier, I'm a strong believer in Type-Driven development. In my view, types are the most effective way to share architectural ideas and pinpoint boundaries in a project. From my experience, teams that frequently run into type and compiler issues often are in projects where no one invested time in defining clear, descriptive types. Defining types in TypeScript goes far beyond writing name: string. It can involve everything from string unions to advanced type transformations. Developers must be careful in this process, dedicating time up front to outline exactly how data will flow through their system. After all, the code itself should merely support what those types describe. This way, even newcomers can quickly understand the project’s core logic just by reviewing the types. In many real-world scenarios, you might do both: define certain critical domains or public-facing entities with an object-driven approach, but keep smaller, short-lived data structures as simple TypeScript types. This hybrid approach may work well if you clearly communicate where and how each method should be used. From my perspective, this works only if you have a really small team. Generally, it's not worth it.

Conclusion

Whether you prefer object-driven development (using libraries like Zod) or type-driven development (leaning on TypeScript’s type system, leveraging type support in libraries Joi), each approach has its role. Object-driven development works in smaller semi-complex systems that are usually not maintained by bigger teams. It definitely makes you spend less time on writing new features in the system. Pre-defined types on the other hand work as single source of truth, but might feel verbose for smaller or transient objects.