2024-09-05
2591
#typescript
Yan Sun
19174
105
Sep 5, 2024 ⋅ 9 min read

Types vs. interfaces in TypeScript

Yan Sun I am a full-stack developer. Love coding, learning, and writing.

Recent posts:

React useEffectEvent: Goodbye to stale closure headaches

React useEffectEvent: Goodbye to stale closure headaches

Discover why the useEffectEvent Hook is important, how to use it effectively, and how it compares to useRef.

David Omotayo
Oct 17, 2025 ⋅ 5 min read
I Tried Shadcn CLI 3.0 — Here’s What I Learned

I tried Shadcn CLI 3.0 — here’s what I learned

Shadcn CLI 3.0 takes component management to a new level. With namespaced registries, private access, and AI-powered discovery, it’s now faster and smarter to build React UIs.

Emmanuel John
Oct 17, 2025 ⋅ 6 min read

Why is Zod so slow?

Zod’s flexibility comes at a cost. This article breaks down why Zod is slower than AOT-compiled validators like Typia, and how to fix it with a build-time optimization that brings production-grade performance.

Ikeh Akinyemi
Oct 16, 2025 ⋅ 5 min read
the replay oct 15 graphic

The Replay (10/15/25): AI’s accessibility problem, React 19.2, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 15th issue.

Matt MacCormack
Oct 15, 2025 ⋅ 34 sec read
View all posts

11 Replies to "Types vs. interfaces in TypeScript"

  1. To me type aliases are more strict, so it makes more sense for me to use that by default – even for objects. The only time I use interfaces is to expose types publicly so that the consumer of your code can extend the types if needed, or when implementing with a class.

  2. In your example of that interface with tupe [string, number] is actually an interface that has one of its members defined as a type (of a tuple) so no confusion here.
    One difference that you didn’t mention is when object implementing some interface can have more properties than the interface defines, but types limit the shape to exactly what type has defined.

  3. “Interfaces are better when you need to define a new object or method of an object. For example, in React applications, when you need to define the props that a specific component is going to receive, it’s ideal to use interface over types”

    There is no argumentation here. “object or method of an object”, while being vague, has nothing to do with a functional React component which is a function.

    You’re just making more confusion.

  4. There are so many errors in this!

    1. “In TypeScript, we can easily extend and implement interfaces. This is not possible with types though.”
    What? Classes can implement types. Types can “extend” types using ‘&’.

    2. “We cannot create an interface combining two types, because it doesn’t work:”
    Again, what? If A and B are interfaces, you can create an interface C like this:

    interface C extends A, B {

    }

    This is a very misleading post.

  5. I, personally, tend towards `type` when defining Prop types.

    The things you get with `interface` (namely `implements`, and the ability to extend through redeclaration) aren’t really useful in the context of Prop definitions, but the things you get with `type` are (namely unions, intersections, and aliases specifically).

    They’re mostly the same in this context, but occasionally you’ll end-up NEEDING to use type so you define PropsWithChildren using the react library type React.PropsWithChildren and since I prefer consistency, I’ll just use type for all PropTypes.

  6. You say, “Interfaces are better when you need to define a new object or method of an object.”, and then straight away in the next box you use a type to define an object.
    “`
    type Person = {
    name: string,
    age: number
    };
    “`
    So which one is it? The article doesn’t seem to adhere to its own advice which is confusing.

  7. Great stuff man, thanks a lot
    Differences between types aliases and interfaces are not easy to understand, and sometimes we don’t know which one to use, that helped me to figure it out better

Leave a Reply

Hey there, want to help make our blog better?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now