use new) in order to be able to use the instanceof, otherwise, it is just an expensive interface. And just as a final note, there are two other options than just classes and interfaces, the first is something called a type, which is pretty similar to an interface, but check this SO post, specifically the 2019 Update answer:Typescript: Interfaces vs Types. The last option is to go functional programming style (not OOP) with TS. How does it affect my end code that runs? Difference between interfaces and classes in Typescript, https://jameshenry.blog/typescript-classes-vs-interfaces/. Also, for simple data classes that dont contain any functions, you can use classes for setting up default values. Now, since they are marked as optional, when you go to use them you will always have to check if they are defined.

Thisshould always be considered. Every time you create an instance you are going to have to set the odometer and lastOilChange to 0 (assuming new cars) and then if you know the make and model you set them. You could create this interface to store data about your car: But what you are unable to do is set any default values. The meat I originally published on Stack Overflow:Difference between interfaces and classes in Typescript. First, there is the obvious difference:syntax. When most people start using Typescript, they run into the inevitable question: Class or Interface? When to use classes: When you want to create objects that have actual function code in them, have a constructor for initialization, and/or you want to create instances of them withnew. How does it affect my design? Notice how it retains ClassExample as an identity for the object butthen classExample1 it doesnt actually have a reference to the ClassExample object this makes instanceof not work. I realized that the answer was not obvious and after nearly 10,000 views, the question on Stack Overflow, Difference between interfaces and classes in Typescript, had not been answered. As a side note, if you look in .d.ts files you will notice that they only use interfaces and types, and thus this is completely removed when transpiled to TS. Now if you were to write it as a class: You can set default values, which will assure you always have a make and model set, albeit they are unknown to start with. Both of these are perfectly acceptable so the you would have to decide for your specific use case which is better. I dont have much experience in this area, but I know that certain libraries, such as Redux, are functional, not OO, so you should know that it exists and it is something different. Lets look at the impact to your JS transpiled code for interfaces: When to use interfaces: Use them when you need to create a contract of the properties and functions for an object that will be used in more than one place in your code, especially more than one file or functions. For further reading you can check outhttps://jameshenry.blog/typescript-classes-vs-interfaces/as well. With functional programming if we wanted to do the above example we could just do: Feel free to pipe in if you have a better Functional Programming example, it is really out of the scope here and should have its own article, but I wanted to briefly touch on it. Now the interesting stuff. They can be implemented or extended but cannot be instantiated (you cantnewthem). : How do I choose which one to use? Another example is if you had an interface with functions in it, like this: Which would require every car to implement functions for drive() and stop() and any other internal components, which could be great unless all cars drive and stop the same way, in which case you could switch to a class that you extend: This really comes down to a conversation about inheritance vs. composition, which is beyond the scope of this answer, I just want to show examples of one vs. the other. This also means that the code is not compiled out, so it will take up more space. This is one key difference mentioned by @Sakuto, but has more implications than just space. The Intersection of Typescript, React and Office Fabric.

You must create an instance of the object (i.e. It means that classes can be typed checked, retaining and understanding of who they are even in the transpiled JS code.

Also, use when you want other objects to start with this base set of properties, such as having multiple classes that all should start with the same set of. Feel free to comment if your team does it differently, I would love to learn why. Another time you would want to use them is when you are doing type checking, though there are workarounds for interfaces if needed (see the interface section OS link). Further differences include: classes can be instantiated usingnewand can be extended, but not implemented. Perhaps the cars arent always new and you always should know the make and model, then having the first interface without making make and model optional may better suite your business needs. Now lets look at the impact to your JS transpiled code for classestoo: Which is the same size in TS,in JS ES5 code it becomes: The size difference is quite substantial, and since I just used it as a type, it added no value. So I sent out to answer the question. Interfaces: Allow for defining a type that will be used during design and compile time for strong typing. The sections about when to use and not to use may be subjective these are the guidelines I give people on my team, but it is possible that other teams will have other guidelines for valid reasons.

Is there actually a difference? Classes: Also allow for defining a type that will be used during design and compile time for strong typing, and, additional, can be used during runtime. To compare and contrast interfaces vs. classes in their compiled codeherewhere you can see the code in typescript playground that will show this example and how it looks in JS. I posted the shortened, non-example version here. I will outline the differences in syntax, and when and when not use to each and what happens to them when they get transpiled to Javascript. This is a simple, but necessary to understand difference: Interface properties can end in commas or semi-colons, however class properties can only end in semi-colons. When not to use classes: When you have a simple data interface, do not need to instantiate (new) it, when you want to have it implemented by other objects, when you want to simply put an interface on an existing object (think type definition files) or when the space it would take up is prohibitive or unwarranted. When not to use interfaces: When you want to have default values, implementations, constructors, or functions (not just signatures). Classes can have constructors and actual function code along with default values for variables. They get removed when transpiling down to JS so they take up no space, but they also cannot be type checked during runtime, so you cant check if a variable implements a specific type at runtime (foo instanceof bar), except by checking the properties it has:Interface type check with Typescript.