DEV Community: A. Rahman Bishal

Of Type and Interface: TypeScript Tales Ch. 01

A. Rahman Bishal — Wed, 19 Nov 2025 09:24:21 +0000

As you are reading this, I’m going to assume that you have a basic idea of what TypeScript is (which is basically JavaScript with syntax for types, according to the official docs). The purpose of this piece of writing is to discuss and look into the contrast between two commonly used constructs widely used in TypeScript: Type, and Interface.

In short, we use type as type aliases, which is, a name for any type. With the help of this, we can use the same type more than once and refer to it by a single name. On the other hand, interface, or interface declaration is basically another way to name an object type, actually a contract for a structure.

Now, they may not seem very similar by the definition. But here we are here, talking about what are the differences, and maybe trying to choose only one between type and interface, there should be some similarities that might make you confused, right?

In a bunch of cases, we can use type and interface interchangeably, and choose them freely. For object shapes and function signatures, both can work the same way. Let’s see an example. We will define objects and functions using both type and interface.

// defining object

type ObjectType = {
  name: string;
  author: number;
  fun(): void;
}

let thrillerBook: ObjectType;

interface ObjectInterface {
  name: string;
  author: number;
  fun(): void;
}

let fantasyBook: ObjectInterface;

// defining function

type FunctionType = (author: string) => string;

const getAcademicAuthor: FunctionType = (author) => {
  return `The academic author is ${author}`;
}

interface FunctionInterface {
  (author: string): string;
}

const getFictionAuthor: FunctionInterface = (author) => {
  return `The fiction author is ${author}`;
}

But yes, there are some obvious differences. Both of the keywords has some superpowers of their own, that the other one does not have. Let’s dive into those.

Superpowers of type

You can use type to represent anything from primitives, unions, tuples, and various complex type. But interface is mostly limited to defining shapes e. g. objects (as well as callable & constructable signatures).

type Title = string;                // primitive
type Published = string | number;   // union
type Binding = [string, string];    // tuples
type Spine = "flat" | "round";      // template literal
type ReadonlyBook = {
  readonly [K in keyof Book]: Book[K];
}                                   // mapped types

There are cases, when we must fall back to using type alias. We can roughly list them down like this:

Union types
Intersection types
Mapped types
Conditional types
Template literal types

These are some mere examples that interface does not support. It can be used for far more complex typing.

Superpowers of interface

While using interface for defining shapes or structure, there are several perks over using type. One of the major distinctions between type and interface is that type cannot be re-opened and redeclared, whereas interface can be. We call this declaration merging.

interface Book {
  title: string;
  author: string;
}

interface Book {
  published: number | string;
  reprint(): void;
}

// we can do this, no error.

Now, if we declare an object of type Book, it will have all the properties from both definitions, i. e. title, author, published, reprint(). But such is not the case for type.

type Movie = {
  title: string;
  released: number;
}

type Movie = {
  director: string;
}

// we cannot do this, TS will throw error.

To achieve the same with type, we must define a new type, and intersect the old one with it. Something like this:

type MovieWithDirector = Movie & {
  director: string;
}

But this method has a little overhead comparing to the one we saw earlier with declaration merging.

Even though declaration merging is one of the biggest superpowers of interface, it comes with a warning label—overusing merging can make the codebase harder to reason about.

Extensions and Implementations

An interface can extend both interface, and a type. Remember the Book interface and the Movie type we defined earlier in the example? Let’s extend those:

// interface extends another interface
interface PaperbackBook extends Book {
  binding: "paperback";
}

// interface extends another type alias
interface AnimatedMovie extends Movie {
  medium: string;
}

But remember, for an interface to be able to extend a type alias, it must be of an object type. For example, the below extension is not possible.

type Magic = number | string | [string, string] | number[];

interface Technology extends Magic {
    ...
}

// this will throw an error

The bottom line is, interfaces can extend other interfaces and sometimes type aliases if they define shapes. But the opposite is not possible in the same way. For that, we have to use intersection, as we did before to mock declaration merging with type aliases.

This scenario remains the same if a class tries to implement either of these. Let’s continue with the previously declared Book interface and Movie type.

// a class implements an interface
class FantasyBook implements Book {
  title = "The Hobbit";
  author = "John Ronald Reuel Tolkien";
  published = 1937;
  reprint() {
    console.log("reprint this again!");
  };
}

// a class implements a type alias
class AnimatedMovie implements Movie {
  title = "Tarzan";
  released = 1999;
  isFavouriteMovie = true; 
}

But, same as before, the type alias must define a shape i.e. an object. Otherwise, it cannot be implemented.

type NoShape = number | string | [string, string] | number[];

class Shape implements NoShape {
    ...
}

// this will throw an error

So, for its very nature, interface can be extended or implemented however we like, without any worries, as they define a shape. But as type alias is more of a broader toolbox for type definition, there are some limitations and cases where we need to be careful.

Now, the end is nigh, and I shall conclude this with a million dollar question:

Type or Interface, which one to use?

As both type and interface share some common use cases, the question is: which one to use?

Well, actually, there is no obvious choice. At the end, it really depends on you. But before deciding that, here are some facts:

TypeScript provides better and more focused error messages while working with interface.
Interface was supposed to be slightly more performant than type. But this difference is practically negligible in most cases (i. e. if the defined type is not very complex or deeply nested), specially in the later versions. After version 4.0, there is no measurable performance difference in real-world scenarios—stated publicly by the TypeScript Team.
Interface has closer mapping with objects by definition.

In case of common use cases, like defining an object, or writing a contract for a class, using interface seems more intuitive from object oriented perspective. But we have no way to avoid type in some cases also i. e. while working with union types or so.

The official TypeScript docs suggests to "Use interfaces until you need to use features from type aliases". This pretty much infers to “Use interfaces to define the shape of objects. Use type aliases for more advanced type composition.” For your convenience, I can provide a decision tree—

Use interface when:

You want declaration merging.
You want cleaner IntelliSense names.
You want the error messages to make more sense.

Use type when:

You need unions, intersections, mapped types, template literals.
You work with utility types (Partial, Pick, etc.).

But if you are still confused, just go with whichever you are comfortable with. But, it is recommended to be consistent on the choice. Choose the approach that better suits your style and keeps the code more readable and maintainable.

Keep in mind that, these are compile-time only constructs. After being compiled into JavaScript, no trace of type or interface remains. So choosing one or another does not affect runtime perfomance.

References

TypeScript Handbook: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html

Playground Examples 1: https://tinyurl.com/4cwazrus

Playground Examples 2: https://tinyurl.com/4hu8ebsy

The Magical CSS Display Property: Contents!

A. Rahman Bishal — Tue, 18 Nov 2025 12:13:08 +0000

There are a bunch of display properties in CSS. If you don’t write CSS frequently, you might have missed a cool property that was introduced relatively recently, though it’s not that old either (started gaining support across major browsers around 2018). Well, I’m talking about display: contents.

What does contents do?

The HTML elements like div, span, etc. are wrapped by an invisible box around themselves where we can specify their paddings, margins, and whatnot. So, in general, we work with boxes. But when display: contents is applied, that box seems to magically vanish. Rather, it will be replaced by its pseudo-elements or child-elements. Or you can say, pseudo-boxes or child-boxes. It’s like that box doesn’t exist. Let’s see an example:

<div id=”parent-contatiner”>
  <div id="container" style="display: contents">
    <h3> I am a Panda! </h3>
    <p> I love a Cat! </p>
  </div>
</div>

The container div will not have a box around it, and it will not be visible. Rather, it will be replaced by its children i. e. the h3 and p elements. So now, they are no longer the container’s children, but the parent-container’s children. It will not be gone from the DOM-Tree, it’s just that the Tree will pretend as if it’s not there. Cool right?

Where do I use contents?

You may ask, if the container itself disappears, all the styles and events will be gone, too? The answer is, no. You will still have the events attached to it, and the only styles you will lose are the styles related to box generation (like margin, padding, border, etc). So, where do we use it?

Well, I can give you two scenarios right away.

First, when you need to wrap something within a content for semantic readability, but doing so will break your design. By using contents, you will be able to stand in a sweet spot where you have both — semantic readability and the required design.

Second, you might face a situation, where all your elements need to be direct children of a container that is using flex or grid. You need to apply some styling on some children based on a condition or so. In that case, you can wrap those children within a container with display: contents based on that condition.

Does this sound like a little gibberish to you? Ok, then let me tell you how I found this property in the first place.

A little practice for you!

Let me explain the problem first. I was working on a responsive web page using a mobile-first approach. I had three boxes. In the desktop view they will be shown side by side, just like Image 1 —

Plain and simple flex-row, right? But in the mobile view, Box2 and Box3 will be shown like a stack and this stack will be side by side with Box1 like Image 2 —

Now, how can you achieve that? Think about it. This will introduce you to contents and you might as well have a little hands-on experience!

Let me give you my solution. (Please note that this might not be the only way. It’s just how I solved it personally, and I think it’s neat!)

I have the three boxes inside a parent-container having display: flex applied. I just wrapped Box2 and Box3 in a container. When we are in the mobile view, this container will have display: flex. So now, Box1 and the container are siblings and flex property will only apply to these two. Box2 and Box3 will have separate flex properties applied to them via the container. But when we are in the desktop view, this container will have display: contents. So, in the desktop view, the container visually disappears, and Box2 and Box3 are direct children of the parent-container. Now all three boxes are siblings and flex property from the parent-container applies to all of them. That’s it.

The code may look like this —

<div class="outer-container">
  <span> Box1 </span>
  <div class="inner-container">
    <span> Box2 </span>
    <span> Box3 </span> 
  </div>
</div>

.outer-container {
  display: flex;
  flex-direction: row;
}

.inner-container {
  display: flex;
  flex-direction: column;
}

@media only screen and (max-width: <breakpoint>px) {
  .inner-container {
    display: contents;
  }
}

A tiny note with warning!
I should mention that this property does not work the same with all the elements. There are some elements that are not rendered purely by the CSS box concepts may behave differently. Please see this doc for further reference.

So, yeah, that’s how I’ve found display: contents, and I think it works like magic. No?