Hey Kyle! Loving all the TS content coming out of your channel. Wanted to drop by with a clarification that probably ALSO needs to be on my types vs interfaces video. When we're talking about performance with types vs interfaces, the difference is negligible when just declaring basic object types. The real performance gap is between intersections (&) and 'extends'. There is a pretty big gulf in performance between them - intersections are bloody hard for TS to resolve and so take a lot longer. Using extends is much easier and also comes with some correctness guarantees. I've seen a lot of folks in the community moving towards interfaces for that reason - interface extends really can speed up your TS codebase by a large factor. I also neglected to mention this in my types vs interface video, it's a nasty little nuance that isn't clear on first look. Love your stuff as always!
But extends and intersections serve different purposes. I think extends and union are more similar. Interfaces have no ability that I'm aware of for intersections.
I think I understand what you mean now. I was thinking of intersections on unions, and they work completely differently on unions. Intersections on object types are indeed basically the same as extends on interfaces. It's a little surprising that it would be a lot slower for types, but I guess that makes sense when they're capable of so much more.
It's not true that you can't use conditions with interfaces in TypeScript. They're actually quite powerful. You don't always need to use extends with interfaces; there's more you can do with them, like combining them together or having conditional types based on their content. Interfaces are great for defining the shape of objects: they're a bit stricter, which is good for making sure your objects have the right structure. Types, on the other hand, are more flexible. They can describe a bunch of different things, not just objects. But because they're so flexible, they can sometimes be too loose for defining objects. That's why, when you want to be really clear about the structure of your objects, it's better to use interfaces instead of types. I don't think you really understood how to use interfaces properly, and this video is misleading on many points.
You can just use the | operator at the variable definition level, or am I wrong? This actually feels like cleaner code to me, because you define your interfaces, and at the var level you define which types to adhere to. And if you use interfaces in that way, I don't see the purpose of renaming base types (losing both advantages you summed up). I'm still pretty new to typescript (though not to programming), so still figuring things out... like: interface i1 { name: string } interface i2 { age: number } const user : i1 | i2 = { name: "test" }
Truly disappointed with this video. Typescript literally tells you "Use interfaces until you need the features of types", but then Kyle makes a video listing all the features of types and saying that's why you should always use types, whether you need those features or not (and a lot of the time, you really don't). Types serve a purpose, interfaces serve a purpose, you should've rather made a video explaining how to know when to use types or interfaces. And the whole mixing types and interfaces in the codebase comment is bogus, that's like saying "Always use 'const' instead of 'let' because const has all these features and let only does this"... Seriously Kyle 🤦♂💔
To me it doesn't really matter that much. I use both, and I don't see how you could ever have it come up as an issue. If something can't be done with a type, use an interface, and same in the other case. They're used the same so it doesn't really matter.
To be very honest, this debate is completely unnecessary for me, I have used both, but I never found i have a huge problem just because i use interface, not type and vice versa.
But you actually supported they advice, because they say you should use types if you need it’s features. And this is what you showed. Personally I dont see an issue with mixing them up, we do it all the time
agreed, problem with coding youtubers is that they've never worked in the last few years so they just keep spouting nonsense that no one cares about at work.
Imagine opening every file and it uses different things, when importing something you never know if it is an interface or type means you never know if you can use generic types or type utility functions is pretty annoying. I’d rate this higher than a lot of other things in terms of things to agree on in a codebase.
@@SpeakChinglishif you use VS Code or most any other IDE then there is no need. Further most the time I just don’t care. Type?? Interface?? Most the time it doesn’t matter. And it is easy to change one to the other when the need arises.
I'm not convinced. I generally use interfaces for objects, and types for single liners like primitives or utility types. I find they play well together and don't see the issue with mixing them any more than mixing variable types.
When you start to wan to make unions/intersections or Omit, pick and many operations you see yourself using types instead of interfaces. The fact is, if you want consistency then you’ll not use interfaces
@@ChibiBlasphem I don't know if I agree with the "consistency" argyment. There are times to use interfaces, and times to use types. I feel like that logic would be consistent with not using any classes becuase you prefer functions. They both have their time and need and though you can pretty much do anything in Javascript with a function, there are times that you should just use a class.
@@justinwallace2321 And the only times when you want to use interfaces is for extending it because it's the only thing type aliases doesn't supports it. In every other cases types alias do the job and you get 1. Consistency, 2. Seeing an interface means it's meant to be extended, so clarity.
1. Types intersection is NOT equal to extending interfaces. Intersect two types like { name: string } & { name: number } an see what happens. And happens "{ name: never }" instead of an error. Good luck tracking that in a project with more or less big types structure. 2. Types for some reason have an implicit index signature, which will bite you when you less expect it. When you denied to pass "just an object" to your func, for example, because that object "does not have an index signature", suddenly. Overall, this whole video sounds like "oh, I cannot use same syntax for two totally different tools with different tasks, so I'll use just one of them". What kind of arguing is that? Please don't do this.
1. To play devil's advocate, that isn't difficult to track in a large project at all. It becomes obvious as soon as you start actually using the `never` type, because then you'll see a type error, and it's no harder to fix than for interfaces (e.g. by removing or `Omit`ting the conflicting key). 2. There's a trade-off here; interfaces' explicit index signatures can also lead to unsafety. I recently tried to make a `Serializable` utility type, but my serializable interfaces weren't assigable to it because TS knows they can be extended to become unserializable (even though I know mine won't be). So I had to make my interfaces extend `interface SerializableRecord { [key: string | number]: Serializable | undefined }`. In a way, this is safer now that nobody can extend my interfaces to be unserializable. But in another way, it's less safe now that I can set nonexistent fields on my interfaces (since they're `Serializable | undefined`) without seeing a TS error, and I may not find out until runtime in production. And not only that, but with the explicit index signature, my classes could no longer implement my interfaces, since classes can't let any string index them. So I was practically forced to use types instead of interfaces.
Still learning here, are you saying interfaces can solve that particular issue? Such as: interface one {name: string} interface two extends one {name: number} that throws an error right? So is the benefit here that with interfaces, this gives an error and we realize sooner so we don't get the issue of "{ name: never }"
@@Nelsonm97 That is what they were saying in their first point, yes. (And I don't think this is an important point in favor of interfaces, as I explained in my previous comment.)
Having come from "classical" OO languages, I tend to use Types for when a thing "IS-A" other_thing. Interfaces are for when a thing "BEHAVES-LIKE" other thing. In other words, use the 2 styles for what your things are, or they do, not based on the capabilities necessarily. Sometimes you have to, of course.
Coming from the same background I agree. Best take good old PHP as a reference which also went from un-typed to typed a long long time ago. Types are for data structures and Interfaces are for "local" functions or API's (remote functions) One of the reasons I don't like TS. The authors created their own scheme instead of building on good and accepted practices
The originl intent from OOP world was that interfaces define a "contract" which classes must honor. If you stick with this mindset then things just make more sense. A type can simple be used when you just want to quick structure and shape data.
I think that the core point is missing. Type describes the properties of an object, interface describes the behaviors. Said that, your choice is driven by this difference. Just my two cents
IMHO This kind of videos foment the use of bad practices with new developers, the whole reason TS exists is to avoid this kind of implementation from JS but i guess they couldnt completely avoid it, the whole point of TS is to have typed variables so you know what to expect with those types you basically return to the old JS way where you could find any type and you wouldn’t know if the type is correct or not, which leads to bugs like NAN, or 1+1 = 11
Naaah. Interface is for object structure. Types, well, for types, primitive style. Why would you want to use interface for the role of a types? I don't get it.
This feels like a rather weak discussion on interface vs types. (1) It's nonsense to say that an interface has a limitation because it can't describe a number or string. Interfaces describe the shape of objects and are themselves a type, and you can create a type which is a union of interfaces. (2) Framing types and interfaces as interchangeable except for one feature difference (interface merging) is the wrong perspective. When they are comparable, i.e., object types vs interfaces, then types are restrictive and interfaces are permissive. This is the better heuristic, as opposed to "just use types". (3) The argument that interfaces are faster is not a mainstream argument and is distracting given how weak it is. Even if it were true it'd be a brittle micro-optimization.
Another benefit of interfaces over types is that errors are so much easier to read. With types, it just spits out every property name which can get crazy when there are a lot of props, wheras with interfaces it just shows the interface name. I tend to use types more than interfaces, but I am torn on the issue because of the error messaging.
@@dhedarkhcustard I don´t think he means it shows you the values of the object. Rather that instead of MyUser it would show { Username: string, Password: string } & { moreStuff: number } & .... Some typescript type declarations get crazy out of hand its not obvious what type you are using when looking at a wall of props like that you don´t even know you are using a type, maybe it´s just inline with the variable and there is no type declaration to be found in your project.
There's nothing complicated about using both types and interfaces in a code base; they each serve a specific purpose. Just like there's nothing complicated about having some variables that are strings and others that are numbers; you use them where they're appropriate, you don't try to homogenized everything to strings. The only issue new developers face is knowing WHEN to use type or interface; telling them to "just use types" does them a huge disservice.
@@king-manu2758 Ironic response since you're misrepresenting mine! I didn't say he said "only use interfaces", where are you getting that idea? He said in the video "I don't like to mix types and interfaces because it makes the codebase more confusing". I responded to that part saying it isn't confusing if you understand the use cases. Further, making a rule like that is going to mislead a lot of devs new to typescript.
@@king-manu2758 Well maybe his advice is actually not quite good? The main idea and purpose of interface is rather semantic. It is meant to be used as a foundation for describing object interfaces. Any kind of interfaces, actually. While using both it is harder to confuse the descriptor purpose, because you can tell simply by looking it's definition, if it is a simple type or some object interface. It's like a convention. For example, we all agreed to have type descriptors starting with the capital letter for the same exact reason - to have a simple distinguishable indicator for descriptor to be variable or type. Although, some have a tendency to use "I" and "T" to differentiate these two entities and exploit "type" whenever they can.
@@soviut303 making a rule like that? What rule are you talking about? When he said he doesn't like to mix types and interfaces he wasn't making a rule, he was stating his personal preference. If you're implying he pushed some rule that interfaces should never be used, then you yourself just admitted that's not the case in your previous post. So then what's this rule you're talking about that this guy supposedly made?
I cannot agree with these reasons at all. Interfaces come from the world of polymorphism (and OO for that matter), while types come from the world of JavaScript being a free for all weak type system, where anything can be anything and thus types are a mandatory feature. Union types make absolutely no sense in case of polymorphism and therefore you don't need them at all in this case. If you decide to refrain from polymorphism that doesn't mean that Interfaces are useless, it's just means you are having completely different approach in modelling your data structures.
All those debates still won't stop me from using only Interfaces for defining structures and using Types only for the computed types. Maybe I'm just a weirdo, but at least to me it seems logical that interface should describe _a thing_ and a type, well, describes what type the properties of that thing are unless there are more structures inside. For me it's still just a matter of preference 🤷♂ structure = interface, it's just my C# side
Well… interfaces are meant to be used for objects. You don't actually need to rewrite an interface to be a non-object representation. You can actually use | and & for interfaces: const response: IErrorResponse | ISuccessResponse = ... Or using a type to alias them: type Response = IErrorResponse | ISuccessResponse const response: Response ---- I only use type for aliases in these cases. But for objects representation, I often prefer using interfaces to mix with classes and implements.
Without having watched the video: I think about it a little bit differently. I generally use types unless I want to 1. Modify/extend a global type outside of my control or 2. If I want to let other code easily extend my interface.
Interfaces are made to represent objects and DTOs. Types are made to make few types work as close as primative types, but it can go as complex as you need.
I feel like the example you give of the "advantage" of types is a bit contrived - If you are really just using a single "type" then you should either let the ts-interpreter automatically infer the type, *or*, just define the type inline, no need for a Type definition if something is really just a string.
One thing you don't mention about the benefits of interfaces over types is that interfaces are more OOP while types are more useful to share data around. Interfaces can have functions that are defined to have patterns that are predictable in your code base where the responsibilities are split between your views and your business logic. But, of course, in the front-end, it has less importance as you're mainly just sharing data around your components.
"More OOP" isn't a selling point. For the typical 'business app' types are the way to go as you shouldn't be using interface merging when you control the source anyway.
"in frontend"? In frontend usually doesn't matter because React is Functional Programming orientated, not because is frontend. You can write backend code in Functional Programming too, in my opinion if you're writing a API you SHOULD write it in Functional Programming, using OOP for unidirectional events is mostly overhead, and in TS can lead to very bad code, for example Nestjs with decorators.
@@adambickford8720 This is the wrong way to frame the topic. It shouldn't be "just use types" or "just use interfaces". For beginners there's already a sufficiently simple heuristic that you shouldn't have to say something so blunt -- object types are restrictive whereas interface types are permissive.
For me interfaces should be used when you want to expose a consistent API and make something open to extension but closed to modification where as use types for stuff you return from methods or functions For example, a database call to fetch a user by ID should return a user *type* but a class responsible for calling the database should implement an *interface*
Simple question, what advantage does it give you other then doing this because it feels right? It doesn't have any advantage at all. Doesn't help you read code faster, doesn't do pretty much anything.
Why though? There's literally nothing in one or the other that offers better suitability for those use cases. Even worse, the caller won't even realize the difference.
@@xromasik Making semantic sense is an advantage in itself. Interfaces make sense when you're going for an object oriented approach since multiple classes can implement multiple interfaces and can be used interchangeably but you cannot make a class implement a type. However I don't see much use of an interface when you're working with a functional approach, so as I said it's better for functions or methods to use types
@@truevelvett Imagine you want to store some sort of data but you don't want to worry about how it's stored (it might be stored in a JSON file, in memory or in an SQL database) Well, simply create an interface that defines a bunch of methods like "addUser", "getUser", "deleteUser", etc and based on your use case implement that interface that stores the user object somewhere. *But now the cool thing is that if in the future you decide to move from let's say storing in a JSON file to storing user details in an SQL server, all you have to do is define a new class that implements the interface that you defined and replace "new UserFileService()" with "new UserSQLService()" without touching the rest of your code*
Anytime someone starts speaking in absolute terms (using words like "always") you know you need to take what they're about to say with a grain of salt.
Simply advocating to use types everywhere because it's one unified thing across your codebase is not the best argument. That's like saying "we'll always use `let` because you can do more than with `const`, so if you only use `const` you'll have to switch some to `let` and then you'll have a mix of `let` and `const` in your code".
After reading the comments I'm convinced that the people hard disagreeing with this take come from the world of OOP and are just used to interfaces. It seems many people don't realise classes can implement types, just like interfaces. In pretty much any situation you would want an interface it can be substituted for a type. So, why is this such a hot debate?
I got your point, but i prefer to use Type like a "primitive" and Interface to describe an object. and... To use OR with interface, you just need to declare 2 or more interfaces and call after, like: interface A { a: string } interface B { b: number } const obj: A | B .... 🙃
I feel like commenting on this will be pointless... I use objects 90% of the time to pass data around. When you need a simple argument for a function you do NOT need a type defined for it because you can inline the type and inference does the rest. Same goes for creating variables, you just inline the type. If you need a union of 2 objects then you make a union type from the interfaces. Interfaces hold you accountable for thinking about what you make and use instead of lazily creating types for everything that doesn't need it. Most of the cases you don't even need to export your interfaces unless you plan to use them inside a callback or something similar. It's funny how much flack I get for using classes and enums when they come with many benefits if you use them correctly.
If you're using mostly Classes in TS, without a doubt your introducing unnecessary overhead to your code, and in my opinion that's very bad. You're like going against the language trying to recreate OOP only languages.
Why is creating types lazy while interfaces are not? You can create an object type and specify that a class implements that type, just like with an interface. I don't see any benefit from using an interface.
I am sorry but for me this is yet another of those videos just for the sake of having a video to stay relevant for the algorithm. And to legitimise it, a typical strawmen at the start by saying this is some kind of larger debate. Its not (as many people in the comments already said).
You should always go interface first because its more readable, declarative and it inherits. Perfect for classes and objects, an arrays can use enums. Then there are generics, extremely powerful in interfaces where usually my custom type starts. But you do you.
There is one advantage to using interfaces that I don’t see mentioned anywhere else. The “references” CodeLens on object properties currently only works with interfaces. So for instance, if you call an api, pass that data to different components all over your app, and make an interface for the returned data instead of a type, you can find all references to the functions or files that consumes that property or find all properties that have no references at all just by glancing at the interface. This can be pretty useful but I’m still team Type.
i'm 0 using typescript, I don't think it is much help for me, eat my time for definition, as Im working as one man show freelancer, not working in a team or company
I have not written that much TypeScript (C# mostly) bud I tend to disagree with this presentation. It may be useful to beginners, but it misses the underlying concepts. You can't prefer interfaces over types, because interfaces... are types! The "interface" syntax defines a type, just like the "type" syntax does; it is only the syntax that is different, but the end result is still a type (just with some twists). Arguing about which syntax to use when both do the same is generally not fruitful. And, of course, as has been pointed out already, the fact that a particular syntax used for a specific thing does not do other things is not really an argument against that syntax. It's like saying numbers are bad because you can't put a string into a number variable. I agree however that silently modifying existing interfaces is not the best default behaviour. A keyword like "partial" would have been better to make the intent clear. That alone is argument enough to prefer the "type" syntax, but otherwise I would still agree with the TS specification here to use "interface" whenever applicable.
I dont see the first problem as a problem. Seems same like saying "you can use either let, or const". It is not complicated or harder to read, both have its use cases, so use it. If you use interfaces, but types for single types/unions, why not?
Coming from OOP into TS I perceive the type/interface distinction to be very poorly designed. There are no clear use cases, they both kinda do the same thing but they don't, the naming is unintuitive, it feels disconnected from JS, and I end up just using what works and fix it when it breaks, which is what TS was supposed to prevent me from doing, or change type/interface on the fly to fit my needs forcing me to be aware of all the other code that references the type, and for a big project - it's painful. It feels like I am fighting with TS all the time. Why isn't there smth like @extendable decorator that you put before a type that lets you extend a type? IDK, it makes no sense to me.
Reason 2 ... could've just done: ``` type SType = {name: string} | {age: number}; interface Test { name?: string; age?: number; } ``` now you should be able to do `const foo: Test = {age: 1};` or const bar: Test = {name: 'hello'};` OR EVENT `const foobar: Test = {name: "hello", age: 1};` you dont have to create a whole new interface to add a new property to an interface, adding `?` makes the prop optional also.
I would generally use interfaces as long as they are faster, but aliases have one major feature, means mapping type MappedTypeWithNewProperties = { [Properties in keyof Type as NewKeyType]: Type[Properties] }
I understand your point, but I'm not entirely convinced. Instead of using 'SType', you could simply use 'string | number' wherever necessary. Why bother defining it as a separate type? In case of the two objects, you can go for an Inteface1 | Interface2 approach. Its completely possible, or am I missing something? interface Broccoli { name: string; } interface Banana { age: number; } const user: Broccoli | Banana = { name: "Doemser" }; same works for the "&" and how often do we have to deal with simple objects like the ones you showed? Additionally, while it's true that code needs to be simple, simplicity doesn't necessarily equate to writing one-liners. For me simplicity means making the code more comprehensible to other developers.. It seems that this boils down to personal or team preference rather than a definitive advantage.
I feel like type more coincides with javascripts natural dynamic nature. So if JS is your first or preferred language you'll feel more at home with type for almost everything only complicate code as much as necessary lol . Where as interface is more rigid like a more strictly OOP language like c# or java for example so people whose go to langage are more along those lines, may see a different reason for using types and interfaces at certain points in their code.
If you ignore OOP using only the type keyword may be fine. To clarify on the interface and type keywords: Implicitely when you define a data structure with no values, you are defining an interface, e.g. { val: string } To use it you give the interface a name, e.g. interface Foo { val: string } The type keyword is a bit misleading. It is essentially an alias for an interface or a combination of interfaces, e.g. type Bar = string | Foo; Writing type Foo = { val: string }; is essentially defining an interface with no name and assigning it to an alias. Why create an alias of an interface instead of using it directly? In programming it‘s always better to use the simplest/minimal approach: If you can use primitive types use them instead of complex interfaces/objects. If you need simple data structures use interfaces. If you need union/or types use the type keyword.
But why not just use a string instead of SType? Also by defining a type as both string and number, you break with the type strong language, so you might as well just use “var” and have it as a variant type.
When you're developing a real world application you should know that you shouldn't use Types. Instead use a Class which gives you the same functionalities of a type plus having methods and lots of more possibilities. Let's say you want to define a User. It has a FirstName and a LastName. You want to show the full name of the user but, of course you don't want to repeat this everywhere: { { firstName + lastName }. That's why you should use a Class. Because you can define everything you want inside it including a FullName method which returns the firstName & lastName combined. Then you can use the method everywhere you want.
If the file is globally-scoped, yes. But if it's a module, it will not merge. Even when each is exported from those separate modules, they will not merge. So modules can really help prevent things like that.
declaration merging can be really handy for exposing interface types from a library, especially when merging with a namespace declaration, e.g. export interface User { ... } export namespace User { export is(obj: any): obj is User { .... } }
What's funny I recently come acrros one of Kyle's video published 2 years ago and his "Welcome to Web Dev simplified, my name is Kyle..." was WAAAAY slower xD Kyle you are developing along with AI ;) Btw. thanks for great content :)
as someone who is used to OOP code this is all quite frustrating to watch. types should be used for types, just like bool, string, int etc. are types or in other words, they should answer the question "What is this thing?". interfaces should be used to define contracts, which should answer the question "What can this thing do?" ... practically this means, that types define the data, whereas interfaces define which methods are available.
You actually CAN do with interfaces what | does for types: just create third interface and make both types extend from it. I know it's mouthful, but it is possible. I personally lean towards types - they remind me of haskell syntax which warms my heart. Oh, and I also dislike this "extending interface" thing - I'd rather see it explicit, like in C# with "partial" keyword.
Synonyms for builtin types? Really? mystring = string? Have you ever tried to read the code of big project where some "developers" created types like this? And what's the point of declaring type as 'string' OR 'number'? If you really need this kind of type, that means your overall architecture is mess. This way of using type just makes code harder to read and harder to understand. Typisation is needed to PREVENT problems, not to create new ones.
Hy Kyle, loving your content usually, but this time .....to be honest, your arguments pro type are not convincing at all. Half of your examples are no valid points as you can do these with interface to. The other half of your examples are rather "horrible" approaches like having a type that can either be string or number (who the hell would do that?) and the other stuff from 04:00 to 05:15 regarding "unions". It also violates best practices, e.g. by "saying" oh my object of type x CAN have a property age, but you could also just leave it out". Sorry, but no! If such an object is supposed to have an age property, you HAVE to have it (set it). You cannot just having it nilly willy there or not there. Plus: Interfaces are more powerful than what you show here (because an interface can declare properties and functions, while type has only properties).
I use types for modeling data (e.g. type User = { name: string }) and interfaces for modeling behavior (e.g. interface UserService { getById(id: Id): User })
May I say that in a world of approximate developers, always in hurry, "restrictive" when features are not needed, or where you are not at all aware in what you doing, it is better(safer?) than "versatile"? That because when you reach a cul-de-sac using interfaces, you forced to ask yourself "am I proceeding in the right way?", then eventually go for types. It might impact with the developing speed, but for sure that improves your software design quality.
People often mix up these two concepts due to a poor understanding of types and interfaces. The purpose of an interface is to provide type information on classes, and this is conceptually distinct from types like strings, integers, or object literals in JavaScript. Given that JavaScript is prototype-based and object-oriented, the notion of classes doesn't truly exist; it's essentially syntactic sugar to emulate classic object-oriented programming. As a result, the use of interfaces in JavaScript doesn't align entirely with their traditional role. However, even in this context, there is a correct and incorrect way to use interfaces. Essentially, if one is working with classes, they should use interfaces; otherwise, they should stick to types. This approach reduces confusion and facilitates a smoother transition to working with genuinely object-oriented languages, such as C#.
I disagree. I'd rather use types for specific usages (like defining a list of string i can use etc). And when i say specific usage : declaring a prop type of number | string | undefined isn't one. If you have a type that is either a object with a name property either an object with a age property.. maybe it's just your code who isn't right at the first place. Even more, you can make class objects with properties if you need even more specific usages. Why is OOP isn't a thing you'd use.
Coming from OOP, these explanations are totally useless, when you give examples of Type compared to Interfaces, because they are meant for totally different things, and if you are using them for specific things in the same way, means you are using them wrong, and your point of judgment is absolutely pointless. Types are descriptions/definitions of objects. And Interfaces are blueprints of what those objects are created for. They meant to cover the whole story behind the scenes and create better understanding for others who work with your Types/objects.
One more bad video. The real difference is what was described as interface benefit. And this can be a big problem of overlapping interfaces, while type cannot be declared more than once in the same scope. So for your own app - it is “safer” to use types. But if you are creating a library - that is vice versa. You better allow people the freedom of the interfaces. The reason 1 is completely mess. Atomic type/interface should not be compared to the union. Some minor thing - alias type was created and was not mentioned as alias. And if we try to talk “practically” - it was mentioned before me that most of the type there are no real problems using both constructs. If you are react dev, who isolates all components, do not reuse/abuse naming or do not export interfaces/types - it doesn’t matter! Make your linter happy and live peacefully. The video should be 30 sec “shorts”, where you show the real difference and warn about possible interfaces merge. Nothing more!
When developers try to fit a square peg in a round hole...SMH. Just learn what the primitives do, then find the appropriate ways to use them. Enough with the bikeshedding. I default to interface unless I need something more complex, like defining a recursive type or a union type like you've shown. I would also argue that defining an intersection type consisting of multiple object types is actually easier and more readable to define with an interface than using the type keyword, provided you are not naming your types using letters of the alphabet.
I think it is not completed answer because type and interface have I different use cases and it is terrible things that documentation is not restrict use cases for each... A `type` is only for describing some data structures without behaviour - if we need to transfer data between some logical parts in out app and this object does not have any behaviour - use `type` - simple data container, dto, response/request model, another complex type... If we need to add some behaviour for our object we need to use `interface` which defines some contract for interaction and could be extended with some inheritance hierarhy... its comes from OOP and in some cases is usefull for FE: - we want to make services reusable and replacable (mocks for testing) - service that is used in many places and we want to refactor it - if have interface that was implemented the developer cant change the contract and its mostly means that out app will not fail after refactoring - all components in any SPA framework is implementing some kind of interface and might be described with it
I think you missed one very important point. In debug when you do types, you never see where the fields come from. If you have a type that combines 5 others, you don't see it in error messages: you see the whole type definition but not what comes from where. Interfaces in this respect behave more like in Java or C#: you always see which interfaces a class implements and which field comes frome where Basically complex types combinations (with | or &) basically create a completely new type without remembering where fields came from. Interfaces always remain named entities
Its one of my pet peeves about typescript tbh. Interfaces vs type is a stupid problem we have to face that I wished was not a thing. Luckily, its not a huuge problem, but still dumb to have to think about vs other typed language’s solutions
Think the last "advantage" of interfaces is a code smell in general. You should not be required to extend external objects and it will break if the interface is renamed on a version update, you are basically coupled to the libraries version if you do this. Maintenance nightmare... And for objects in the own repository you could just create a wrapper or extend the existing attribute.
type cannot be overwritten but you can overwrite interface.. for example use type to model and validate data type in the props of a UI component, so imagine you are bulding e-commerce application you have a customer object from a data base this object has a lot of connections to order object and other objects, and you're in the front-bulding an `order-history` page for the customer, your component will need order history list of specific customer and maybe a links to products in this order list and date or maybe payment method or delviery type now you're infornt of a combination of data types from more than one object, then create a `type` to model and validate the data for your UI component, you can use interface ofcourse but interface meant for customer object itself while type it could be a data in UI props or state.
Types are crap to maintain crappy js compatibility, read sintatic sugar, to please js hardcore, read non realistic codees, devs..ish. Even Crockford is telling us that js must go!
For reason number one, if you need to type something as string, why don't you just type it as string directly? And let's be honest, you can only do this for primitive types anyway, why would you even want to use `type Stype` in the first place? It sounds like creating a problem first and then finding the solution.
The difference between a good coder and a good engineer is knowing when to use your tools properly and not just relying on a single paradigm. Interfaces for object types and types for typed instances. Inheritance can only be done with interfaces and helps with conceptually linking your objects. Wouldn't you rather have an interface that extends your shape rather than define a type that has a union of all shapes? This concept is like always resorting to const objects for your functions to avoid changing "this"
You are confusing your likes with a code smell... only because you like to use something does not mean all the people hace used it. You does not govern reasons to use type, you just explain when you really need to use type (which is the first and second example), and that's all. All your arguments was "I like to use type". There is no differences on almost all the practical cases. You ca use both and you can understand both. There is no code smell.
Most people here defending interfaces have no clue why they are using them lol. Saying that using both interfaces and types is a good practise just because semantically it can make sense (from OOP) is really stupid. If you do something in code just because you think its right without gaining any real advantage, then you are just a bad developer. Using both interfaces and types in a codebase doesn't give you any advantage at all. It's not easier to read a it's not easier to use. Unless for some specific reason you really need to use interface, its always better to use types. There is really no point in mixing those just because someone told you to do so...
pretty much don't agree at all but one part of this seems especially unreasonable and maybe someone can just explain it to me. Why the hell you would like to have in your code something like this "type SType = string"?
Usually i like your videos. But for this one I'm sorry to say i think you're wrong. Its not about one being better than the other. - type is for describing a data structure. - interface is for describing behavior of an object.
Aaaaaand another video telling us to not use some specific feature of a language. The arguments are always incomplete and gloss over some advantages of using this feature (here for example Kyle did not mention how useful interfaces are for implementing classes). Even though the reality is kind of boring, it is what it is: IT DEPENDS. But this doesn't generate clicks right? I have used types and interfaces, they both have their use cases.
Hey Kyle! Loving all the TS content coming out of your channel.
Wanted to drop by with a clarification that probably ALSO needs to be on my types vs interfaces video.
When we're talking about performance with types vs interfaces, the difference is negligible when just declaring basic object types. The real performance gap is between intersections (&) and 'extends'. There is a pretty big gulf in performance between them - intersections are bloody hard for TS to resolve and so take a lot longer. Using extends is much easier and also comes with some correctness guarantees. I've seen a lot of folks in the community moving towards interfaces for that reason - interface extends really can speed up your TS codebase by a large factor.
I also neglected to mention this in my types vs interface video, it's a nasty little nuance that isn't clear on first look.
Love your stuff as always!
I wanna kiss your forehead every waking hour 💋
But extends and intersections serve different purposes. I think extends and union are more similar. Interfaces have no ability that I'm aware of for intersections.
I think I understand what you mean now. I was thinking of intersections on unions, and they work completely differently on unions. Intersections on object types are indeed basically the same as extends on interfaces. It's a little surprising that it would be a lot slower for types, but I guess that makes sense when they're capable of so much more.
Speed up transpiling or runtime?
@@kevinclark1783 Transpiling
You should definitely read about what interfaces are used for
I don't see why you would oppose using both, doesn't complicate the code at all.
Excellent video. I like how fast you speak because you get across what you want to say really quickly.
I use interfaces for function props and class definitions and types for everything else.
I totally agree about this, use type by default
Please make a tutorial: NodeJS (web api) + htmx (frontend), simple CRUD operations
It's not true that you can't use conditions with interfaces in TypeScript. They're actually quite powerful.
You don't always need to use extends with interfaces; there's more you can do with them, like combining them together or having conditional types based on their content. Interfaces are great for defining the shape of objects: they're a bit stricter, which is good for making sure your objects have the right structure.
Types, on the other hand, are more flexible. They can describe a bunch of different things, not just objects. But because they're so flexible, they can sometimes be too loose for defining objects. That's why, when you want to be really clear about the structure of your objects, it's better to use interfaces instead of types.
I don't think you really understood how to use interfaces properly, and this video is misleading on many points.
You can just use the | operator at the variable definition level, or am I wrong? This actually feels like cleaner code to me, because you define your interfaces, and at the var level you define which types to adhere to. And if you use interfaces in that way, I don't see the purpose of renaming base types (losing both advantages you summed up).
I'm still pretty new to typescript (though not to programming), so still figuring things out...
like:
interface i1 {
name: string
}
interface i2 {
age: number
}
const user : i1 | i2 = { name: "test" }
actually type concept is a bit weird (too dynamic, not oop). but as it supports with vs code, therefore it's fine
Truly disappointed with this video. Typescript literally tells you "Use interfaces until you need the features of types", but then Kyle makes a video listing all the features of types and saying that's why you should always use types, whether you need those features or not (and a lot of the time, you really don't). Types serve a purpose, interfaces serve a purpose, you should've rather made a video explaining how to know when to use types or interfaces.
And the whole mixing types and interfaces in the codebase comment is bogus, that's like saying "Always use 'const' instead of 'let' because const has all these features and let only does this"...
Seriously Kyle 🤦♂💔
Object oriented, mutable code benefits greatly from interfaces
To me it doesn't really matter that much. I use both, and I don't see how you could ever have it come up as an issue. If something can't be done with a type, use an interface, and same in the other case. They're used the same so it doesn't really matter.
the only thing i see is that he ain't using copilot 😂 he's the resistance XD, but also no line numbers??? gg good point bro!
To be very honest, this debate is completely unnecessary for me, I have used both, but I never found i have a huge problem just because i use interface, not type and vice versa.
Kyle is great. But most RUclipsrs need new content so yeah many times it’s not a big deal.
It's not a big deal but Consistency is good. Makes the code more readable
I find for exemple that the first reason is not really a problem
But you actually supported they advice, because they say you should use types if you need it’s features. And this is what you showed.
Personally I dont see an issue with mixing them up, we do it all the time
agreed, problem with coding youtubers is that they've never worked in the last few years so they just keep spouting nonsense that no one cares about at work.
If having to use types and interfaces together in the same codebase is your biggest problem then you are really having a sweet life
I was feeling the same thing 😅
Imagine opening every file and it uses different things, when importing something you never know if it is an interface or type means you never know if you can use generic types or type utility functions is pretty annoying. I’d rate this higher than a lot of other things in terms of things to agree on in a codebase.
@@SpeakChinglish There is a convention devs use:
Add 'I' to the name of an interface and 'T' to the name of a type.
IUser, TUser.
@@imdanteasynot all developers do that. Seeing such makes me want to puke.
@@SpeakChinglishif you use VS Code or most any other IDE then there is no need. Further most the time I just don’t care. Type?? Interface?? Most the time it doesn’t matter. And it is easy to change one to the other when the need arises.
I'm not convinced. I generally use interfaces for objects, and types for single liners like primitives or utility types. I find they play well together and don't see the issue with mixing them any more than mixing variable types.
When you start to wan to make unions/intersections or Omit, pick and many operations you see yourself using types instead of interfaces. The fact is, if you want consistency then you’ll not use interfaces
@@ChibiBlasphem that's what i mean by utility types. Types work well for single liners.
js, primitives (￢ ￢)
@@ChibiBlasphem I don't know if I agree with the "consistency" argyment. There are times to use interfaces, and times to use types. I feel like that logic would be consistent with not using any classes becuase you prefer functions. They both have their time and need and though you can pretty much do anything in Javascript with a function, there are times that you should just use a class.
@@justinwallace2321 And the only times when you want to use interfaces is for extending it because it's the only thing type aliases doesn't supports it. In every other cases types alias do the job and you get 1. Consistency, 2. Seeing an interface means it's meant to be extended, so clarity.
1. Types intersection is NOT equal to extending interfaces.
Intersect two types like { name: string } & { name: number } an see what happens.
And happens "{ name: never }" instead of an error. Good luck tracking that in a project with more or less big types structure.
2. Types for some reason have an implicit index signature, which will bite you when you less expect it. When you denied to pass "just an object" to your func, for example, because that object "does not have an index signature", suddenly.
Overall, this whole video sounds like "oh, I cannot use same syntax for two totally different tools with different tasks, so I'll use just one of them". What kind of arguing is that? Please don't do this.
Fax
When this guy uploads a video, I always go to the comments to see the real LPT. I should thank him for that at least.
1. To play devil's advocate, that isn't difficult to track in a large project at all. It becomes obvious as soon as you start actually using the `never` type, because then you'll see a type error, and it's no harder to fix than for interfaces (e.g. by removing or `Omit`ting the conflicting key).
2. There's a trade-off here; interfaces' explicit index signatures can also lead to unsafety. I recently tried to make a `Serializable` utility type, but my serializable interfaces weren't assigable to it because TS knows they can be extended to become unserializable (even though I know mine won't be). So I had to make my interfaces extend `interface SerializableRecord { [key: string | number]: Serializable | undefined }`. In a way, this is safer now that nobody can extend my interfaces to be unserializable. But in another way, it's less safe now that I can set nonexistent fields on my interfaces (since they're `Serializable | undefined`) without seeing a TS error, and I may not find out until runtime in production. And not only that, but with the explicit index signature, my classes could no longer implement my interfaces, since classes can't let any string index them. So I was practically forced to use types instead of interfaces.
Still learning here, are you saying interfaces can solve that particular issue? Such as:
interface one {name: string}
interface two extends one {name: number}
that throws an error right? So is the benefit here that with interfaces, this gives an error and we realize sooner so we don't get the issue of "{ name: never }"
@@Nelsonm97 That is what they were saying in their first point, yes. (And I don't think this is an important point in favor of interfaces, as I explained in my previous comment.)
Having come from "classical" OO languages, I tend to use Types for when a thing "IS-A" other_thing. Interfaces are for when a thing "BEHAVES-LIKE" other thing. In other words, use the 2 styles for what your things are, or they do, not based on the capabilities necessarily. Sometimes you have to, of course.
This, exactly. To me, a type defines what an object (or primitive) *is*, while an interface defines *how I can use it*.
Coming from the same background I agree. Best take good old PHP as a reference which also went from un-typed to typed a long long time ago. Types are for data structures and Interfaces are for "local" functions or API's (remote functions) One of the reasons I don't like TS. The authors created their own scheme instead of building on good and accepted practices
U wot m8?
Still makes no sense as you can define behavior in both. Typescript should never have added these as 2 separate items.
The originl intent from OOP world was that interfaces define a "contract" which classes must honor. If you stick with this mindset then things just make more sense. A type can simple be used when you just want to quick structure and shape data.
I think that the core point is missing. Type describes the properties of an object, interface describes the behaviors.
Said that, your choice is driven by this difference. Just my two cents
IMHO This kind of videos foment the use of bad practices with new developers, the whole reason TS exists is to avoid this kind of implementation from JS but i guess they couldnt completely avoid it, the whole point of TS is to have typed variables so you know what to expect with those types you basically return to the old JS way where you could find any type and you wouldn’t know if the type is correct or not, which leads to bugs like NAN, or 1+1 = 11
Naaah. Interface is for object structure. Types, well, for types, primitive style. Why would you want to use interface for the role of a types? I don't get it.
It's quite the opposite. He wants to use types for the role of interfaces
This feels like a rather weak discussion on interface vs types.
(1) It's nonsense to say that an interface has a limitation because it can't describe a number or string. Interfaces describe the shape of objects and are themselves a type, and you can create a type which is a union of interfaces.
(2) Framing types and interfaces as interchangeable except for one feature difference (interface merging) is the wrong perspective. When they are comparable, i.e., object types vs interfaces, then types are restrictive and interfaces are permissive. This is the better heuristic, as opposed to "just use types".
(3) The argument that interfaces are faster is not a mainstream argument and is distracting given how weak it is. Even if it were true it'd be a brittle micro-optimization.
I use interfaces to enforce the shape of classes.
Another benefit of interfaces over types is that errors are so much easier to read. With types, it just spits out every property name which can get crazy when there are a lot of props, wheras with interfaces it just shows the interface name. I tend to use types more than interfaces, but I am torn on the issue because of the error messaging.
How is showing just the interface name better than showing the exact parts of the type that break better?
@@dhedarkhcustard I don´t think he means it shows you the values of the object. Rather that instead of MyUser it would show { Username: string, Password: string } & { moreStuff: number } & .... Some typescript type declarations get crazy out of hand its not obvious what type you are using when looking at a wall of props like that you don´t even know you are using a type, maybe it´s just inline with the variable and there is no type declaration to be found in your project.
There's nothing complicated about using both types and interfaces in a code base; they each serve a specific purpose. Just like there's nothing complicated about having some variables that are strings and others that are numbers; you use them where they're appropriate, you don't try to homogenized everything to strings. The only issue new developers face is knowing WHEN to use type or interface; telling them to "just use types" does them a huge disservice.
He didn't say only use interfaces, he said use types unless you need the features of interfaces. Misrepresenting someone's argument is not cool.
This is the perfect answer to this video. I feel like this video will just confuse new developers and push them into a bad practice
@@king-manu2758 Ironic response since you're misrepresenting mine! I didn't say he said "only use interfaces", where are you getting that idea? He said in the video "I don't like to mix types and interfaces because it makes the codebase more confusing". I responded to that part saying it isn't confusing if you understand the use cases. Further, making a rule like that is going to mislead a lot of devs new to typescript.
@@king-manu2758 Well maybe his advice is actually not quite good? The main idea and purpose of interface is rather semantic. It is meant to be used as a foundation for describing object interfaces. Any kind of interfaces, actually.
While using both it is harder to confuse the descriptor purpose, because you can tell simply by looking it's definition, if it is a simple type or some object interface.
It's like a convention. For example, we all agreed to have type descriptors starting with the capital letter for the same exact reason - to have a simple distinguishable indicator for descriptor to be variable or type.
Although, some have a tendency to use "I" and "T" to differentiate these two entities and exploit "type" whenever they can.
@@soviut303 making a rule like that? What rule are you talking about? When he said he doesn't like to mix types and interfaces he wasn't making a rule, he was stating his personal preference. If you're implying he pushed some rule that interfaces should never be used, then you yourself just admitted that's not the case in your previous post. So then what's this rule you're talking about that this guy supposedly made?
I cannot agree with these reasons at all. Interfaces come from the world of polymorphism (and OO for that matter), while types come from the world of JavaScript being a free for all weak type system, where anything can be anything and thus types are a mandatory feature. Union types make absolutely no sense in case of polymorphism and therefore you don't need them at all in this case. If you decide to refrain from polymorphism that doesn't mean that Interfaces are useless, it's just means you are having completely different approach in modelling your data structures.
All those debates still won't stop me from using only Interfaces for defining structures and using Types only for the computed types. Maybe I'm just a weirdo, but at least to me it seems logical that interface should describe _a thing_ and a type, well, describes what type the properties of that thing are unless there are more structures inside. For me it's still just a matter of preference 🤷♂ structure = interface, it's just my C# side
Well… interfaces are meant to be used for objects. You don't actually need to rewrite an interface to be a non-object representation. You can actually use | and & for interfaces:
const response: IErrorResponse | ISuccessResponse = ...
Or using a type to alias them:
type Response = IErrorResponse | ISuccessResponse
const response: Response
----
I only use type for aliases in these cases. But for objects representation, I often prefer using interfaces to mix with classes and implements.
This is how types should be used. to alias two interfaces. As you say, interfaces are for defining objects.
Without having watched the video: I think about it a little bit differently. I generally use types unless I want to 1. Modify/extend a global type outside of my control or 2. If I want to let other code easily extend my interface.
Is this guy running out of contents to output? Because this video was super unnecessary.
Interfaces are made to represent objects and DTOs.
Types are made to make few types work as close as primative types, but it can go as complex as you need.
I feel like the example you give of the "advantage" of types is a bit contrived - If you are really just using a single "type" then you should either let the ts-interpreter automatically infer the type, *or*, just define the type inline, no need for a Type definition if something is really just a string.
Pro tip :
If you’re defining an interface, use interface
If you’re defining a type, use type
You’re welcome
🙂
One thing you don't mention about the benefits of interfaces over types is that interfaces are more OOP while types are more useful to share data around. Interfaces can have functions that are defined to have patterns that are predictable in your code base where the responsibilities are split between your views and your business logic. But, of course, in the front-end, it has less importance as you're mainly just sharing data around your components.
Yep. looks like Kyle doesn't do much OOP at all to understand the difference.
@@harag9 You can make class implement a type if that type is nonunion object-like type. No any difference for OOP.
"More OOP" isn't a selling point. For the typical 'business app' types are the way to go as you shouldn't be using interface merging when you control the source anyway.
"in frontend"? In frontend usually doesn't matter because React is Functional Programming orientated, not because is frontend. You can write backend code in Functional Programming too, in my opinion if you're writing a API you SHOULD write it in Functional Programming, using OOP for unidirectional events is mostly overhead, and in TS can lead to very bad code, for example Nestjs with decorators.
@@adambickford8720 This is the wrong way to frame the topic. It shouldn't be "just use types" or "just use interfaces". For beginners there's already a sufficiently simple heuristic that you shouldn't have to say something so blunt -- object types are restrictive whereas interface types are permissive.
For me interfaces should be used when you want to expose a consistent API and make something open to extension but closed to modification where as use types for stuff you return from methods or functions
For example, a database call to fetch a user by ID should return a user *type* but a class responsible for calling the database should implement an *interface*
Yeah that sounds pretty solid.
Simple question, what advantage does it give you other then doing this because it feels right? It doesn't have any advantage at all. Doesn't help you read code faster, doesn't do pretty much anything.
Why though? There's literally nothing in one or the other that offers better suitability for those use cases. Even worse, the caller won't even realize the difference.
@@xromasik Making semantic sense is an advantage in itself. Interfaces make sense when you're going for an object oriented approach since multiple classes can implement multiple interfaces and can be used interchangeably but you cannot make a class implement a type.
However I don't see much use of an interface when you're working with a functional approach, so as I said it's better for functions or methods to use types
@@truevelvett Imagine you want to store some sort of data but you don't want to worry about how it's stored (it might be stored in a JSON file, in memory or in an SQL database)
Well, simply create an interface that defines a bunch of methods like "addUser", "getUser", "deleteUser", etc and based on your use case implement that interface that stores the user object somewhere.
*But now the cool thing is that if in the future you decide to move from let's say storing in a JSON file to storing user details in an SQL server, all you have to do is define a new class that implements the interface that you defined and replace "new UserFileService()" with "new UserSQLService()" without touching the rest of your code*
Anytime someone starts speaking in absolute terms (using words like "always") you know you need to take what they're about to say with a grain of salt.
Simply advocating to use types everywhere because it's one unified thing across your codebase is not the best argument. That's like saying "we'll always use `let` because you can do more than with `const`, so if you only use `const` you'll have to switch some to `let` and then you'll have a mix of `let` and `const` in your code".
I really like your videos but here you've completely misunderstood what is a type and what is an interface.
After reading the comments I'm convinced that the people hard disagreeing with this take come from the world of OOP and are just used to interfaces. It seems many people don't realise classes can implement types, just like interfaces. In pretty much any situation you would want an interface it can be substituted for a type. So, why is this such a hot debate?
Clarity: they do different things 🙂
Sorry but it seems that you don't understand oop fundamentals.
I got your point, but i prefer to use Type like a "primitive" and Interface to describe an object.
and... To use OR with interface, you just need to declare 2 or more interfaces and call after, like:
interface A {
a: string
}
interface B {
b: number
}
const obj: A | B ....
🙃
Thank you! I really like this pattern too.
I feel like commenting on this will be pointless...
I use objects 90% of the time to pass data around.
When you need a simple argument for a function you do NOT need a type defined for it because you can inline the type and inference does the rest.
Same goes for creating variables, you just inline the type.
If you need a union of 2 objects then you make a union type from the interfaces.
Interfaces hold you accountable for thinking about what you make and use instead of lazily creating types for everything that doesn't need it.
Most of the cases you don't even need to export your interfaces unless you plan to use them inside a callback or something similar.
It's funny how much flack I get for using classes and enums when they come with many benefits if you use them correctly.
If you're using mostly Classes in TS, without a doubt your introducing unnecessary overhead to your code, and in my opinion that's very bad. You're like going against the language trying to recreate OOP only languages.
Why is creating types lazy while interfaces are not? You can create an object type and specify that a class implements that type, just like with an interface. I don't see any benefit from using an interface.
I am sorry but for me this is yet another of those videos just for the sake of having a video to stay relevant for the algorithm. And to legitimise it, a typical strawmen at the start by saying this is some kind of larger debate. Its not (as many people in the comments already said).
wtf, just use the interface and make your life actually simple, because it should be....
Wtf ? You're just doing bad code and don't know what a interface is used for ? Please beginners don't listen to that advice
"Stop doing this", you mean stupid clickbait titles and thumbnails?
You should always go interface first because its more readable, declarative and it inherits. Perfect for classes and objects, an arrays can use enums. Then there are generics, extremely powerful in interfaces where usually my custom type starts. But you do you.
These developer debates are nonsense. Get a life guys. Use both.
I think interfaces are better for API responses
interface SType {text: string} easy man.
There is one advantage to using interfaces that I don’t see mentioned anywhere else. The “references” CodeLens on object properties currently only works with interfaces. So for instance, if you call an api, pass that data to different components all over your app, and make an interface for the returned data instead of a type, you can find all references to the functions or files that consumes that property or find all properties that have no references at all just by glancing at the interface. This can be pretty useful but I’m still team Type.
Yes no one seems to to talk about it. But this could be improved bye the ide
Well, I use interface, generics and types as well.
i'm 0 using typescript, I don't think it is much help for me, eat my time for definition, as Im working as one man show freelancer, not working in a team or company
I have not written that much TypeScript (C# mostly) bud I tend to disagree with this presentation. It may be useful to beginners, but it misses the underlying concepts. You can't prefer interfaces over types, because interfaces... are types! The "interface" syntax defines a type, just like the "type" syntax does; it is only the syntax that is different, but the end result is still a type (just with some twists). Arguing about which syntax to use when both do the same is generally not fruitful. And, of course, as has been pointed out already, the fact that a particular syntax used for a specific thing does not do other things is not really an argument against that syntax. It's like saying numbers are bad because you can't put a string into a number variable.
I agree however that silently modifying existing interfaces is not the best default behaviour. A keyword like "partial" would have been better to make the intent clear. That alone is argument enough to prefer the "type" syntax, but otherwise I would still agree with the TS specification here to use "interface" whenever applicable.
I dont see the first problem as a problem. Seems same like saying "you can use either let, or const". It is not complicated or harder to read, both have its use cases, so use it. If you use interfaces, but types for single types/unions, why not?
just wasted 7 minutes of my life....
`interface IUser {name: string; age: number;}` vs `type TUser {name: string; age: number;}` vs `class User { constructor(public name: string, public age: number) {}}`
Coming from OOP into TS I perceive the type/interface distinction to be very poorly designed. There are no clear use cases, they both kinda do the same thing but they don't, the naming is unintuitive, it feels disconnected from JS, and I end up just using what works and fix it when it breaks, which is what TS was supposed to prevent me from doing, or change type/interface on the fly to fit my needs forcing me to be aware of all the other code that references the type, and for a big project - it's painful. It feels like I am fighting with TS all the time. Why isn't there smth like @extendable decorator that you put before a type that lets you extend a type? IDK, it makes no sense to me.
Exactly my point. TS creates its own incomplete paradigm and did not borrow from accepted better ones
Can class implement type?
Reason 2 ... could've just done:
```
type SType = {name: string} | {age: number};
interface Test {
name?: string;
age?: number;
}
```
now you should be able to do `const foo: Test = {age: 1};` or const bar: Test = {name: 'hello'};` OR EVENT `const foobar: Test = {name: "hello", age: 1};`
you dont have to create a whole new interface to add a new property to an interface, adding `?` makes the prop optional also.
I would generally use interfaces as long as they are faster, but aliases have one major feature, means mapping
type MappedTypeWithNewProperties = {
[Properties in keyof Type as NewKeyType]: Type[Properties]
}
The reason #2 is BS. It's a non-issue. Just declare two interfaces, and you have the same stuff with | describing the type for your variable.
I understand your point, but I'm not entirely convinced. Instead of using 'SType', you could simply use 'string | number' wherever necessary. Why bother defining it as a separate type?
In case of the two objects, you can go for an Inteface1 | Interface2 approach. Its completely possible, or am I missing something?
interface Broccoli {
name: string;
}
interface Banana {
age: number;
}
const user: Broccoli | Banana = { name: "Doemser" };
same works for the "&" and how often do we have to deal with simple objects like the ones you showed?
Additionally, while it's true that code needs to be simple, simplicity doesn't necessarily equate to writing one-liners. For me simplicity means making the code more comprehensible to other developers..
It seems that this boils down to personal or team preference rather than a definitive advantage.
I feel like type more coincides with javascripts natural dynamic nature. So if JS is your first or preferred language you'll feel more at home with type for almost everything only complicate code as much as necessary lol . Where as interface is more rigid like a more strictly OOP language like c# or java for example so people whose go to langage are more along those lines, may see a different reason for using types and interfaces at certain points in their code.
If you ignore OOP using only the type keyword may be fine.
To clarify on the interface and type keywords:
Implicitely when you define a data structure with no values, you are defining an interface, e.g. { val: string }
To use it you give the interface a name, e.g. interface Foo { val: string }
The type keyword is a bit misleading. It is essentially an alias for an interface or a combination of interfaces, e.g. type Bar = string | Foo;
Writing type Foo = { val: string }; is essentially defining an interface with no name and assigning it to an alias. Why create an alias of an interface instead of using it directly?
In programming it‘s always better to use the simplest/minimal approach:
If you can use primitive types use them instead of complex interfaces/objects.
If you need simple data structures use interfaces.
If you need union/or types use the type keyword.
But why not just use a string instead of SType? Also by defining a type as both string and number, you break with the type strong language, so you might as well just use “var” and have it as a variant type.
When you're developing a real world application you should know that you shouldn't use Types. Instead use a Class which gives you the same functionalities of a type plus having methods and lots of more possibilities. Let's say you want to define a User. It has a FirstName and a LastName. You want to show the full name of the user but, of course you don't want to repeat this everywhere: { { firstName + lastName }. That's why you should use a Class. Because you can define everything you want inside it including a FullName method which returns the firstName & lastName combined. Then you can use the method everywhere you want.
Does this overriding of interfaces with the same name happen as well if they're in different files? because that could be a problem
If the file is globally-scoped, yes. But if it's a module, it will not merge. Even when each is exported from those separate modules, they will not merge. So modules can really help prevent things like that.
@@offroaders123 nice, thanks for clarifying.
You can actually use interface with single types. For example like this:
```
interface IString extends String {}
const val: IString = 'foo'
```
declaration merging can be really handy for exposing interface types from a library, especially when merging with a namespace declaration, e.g.
export interface User { ... }
export namespace User {
export is(obj: any): obj is User { .... }
}
What's funny I recently come acrros one of Kyle's video published 2 years ago and his "Welcome to Web Dev simplified, my name is Kyle..." was WAAAAY slower xD Kyle you are developing along with AI ;) Btw. thanks for great content :)
as someone who is used to OOP code this is all quite frustrating to watch. types should be used for types, just like bool, string, int etc. are types or in other words, they should answer the question "What is this thing?". interfaces should be used to define contracts, which should answer the question "What can this thing do?" ... practically this means, that types define the data, whereas interfaces define which methods are available.
You actually CAN do with interfaces what | does for types: just create third interface and make both types extend from it. I know it's mouthful, but it is possible. I personally lean towards types - they remind me of haskell syntax which warms my heart. Oh, and I also dislike this "extending interface" thing - I'd rather see it explicit, like in C# with "partial" keyword.
Would you cover making a type definition library with typescript for a vanilla javascript library to improve intellisense?
Synonyms for builtin types? Really? mystring = string? Have you ever tried to read the code of big project where some "developers" created types like this? And what's the point of declaring type as 'string' OR 'number'? If you really need this kind of type, that means your overall architecture is mess. This way of using type just makes code harder to read and harder to understand. Typisation is needed to PREVENT problems, not to create new ones.
the fact that types cant do the one ting interfaces can, might be by design.. ;) the part where you shoot the foot might be exactly why
Hy Kyle, loving your content usually, but this time .....to be honest, your arguments pro type are not convincing at all. Half of your examples are no valid points as you can do these with interface to. The other half of your examples are rather "horrible" approaches like having a type that can either be string or number (who the hell would do that?) and the other stuff from 04:00 to 05:15 regarding "unions". It also violates best practices, e.g. by "saying" oh my object of type x CAN have a property age, but you could also just leave it out". Sorry, but no! If such an object is supposed to have an age property, you HAVE to have it (set it). You cannot just having it nilly willy there or not there.
Plus: Interfaces are more powerful than what you show here (because an interface can declare properties and functions, while type has only properties).
I use types for modeling data (e.g. type User = { name: string }) and interfaces for modeling behavior (e.g. interface UserService { getById(id: Id): User })
Interface X { id: string }
Interface X { name: string }
x interface will be: { id: string, name : string }
This is not doable with type.
May I say that in a world of approximate developers, always in hurry, "restrictive" when features are not needed, or where you are not at all aware in what you doing, it is better(safer?) than "versatile"?
That because when you reach a cul-de-sac using interfaces, you forced to ask yourself "am I proceeding in the right way?", then eventually go for types.
It might impact with the developing speed, but for sure that improves your software design quality.
People often mix up these two concepts due to a poor understanding of types and interfaces. The purpose of an interface is to provide type information on classes, and this is conceptually distinct from types like strings, integers, or object literals in JavaScript. Given that JavaScript is prototype-based and object-oriented, the notion of classes doesn't truly exist; it's essentially syntactic sugar to emulate classic object-oriented programming. As a result, the use of interfaces in JavaScript doesn't align entirely with their traditional role.
However, even in this context, there is a correct and incorrect way to use interfaces. Essentially, if one is working with classes, they should use interfaces; otherwise, they should stick to types. This approach reduces confusion and facilitates a smoother transition to working with genuinely object-oriented languages, such as C#.
I disagree.
I'd rather use types for specific usages (like defining a list of string i can use etc).
And when i say specific usage : declaring a prop type of number | string | undefined isn't one.
If you have a type that is either a object with a name property either an object with a age property.. maybe it's just your code who isn't right at the first place.
Even more, you can make class objects with properties if you need even more specific usages.
Why is OOP isn't a thing you'd use.
Coming from OOP, these explanations are totally useless, when you give examples of Type compared to Interfaces, because they are meant for totally different things, and if you are using them for specific things in the same way, means you are using them wrong, and your point of judgment is absolutely pointless.
Types are descriptions/definitions of objects. And Interfaces are blueprints of what those objects are created for. They meant to cover the whole story behind the scenes and create better understanding for others who work with your Types/objects.
One more bad video. The real difference is what was described as interface benefit. And this can be a big problem of overlapping interfaces, while type cannot be declared more than once in the same scope. So for your own app - it is “safer” to use types. But if you are creating a library - that is vice versa. You better allow people the freedom of the interfaces.
The reason 1 is completely mess. Atomic type/interface should not be compared to the union.
Some minor thing - alias type was created and was not mentioned as alias.
And if we try to talk “practically” - it was mentioned before me that most of the type there are no real problems using both constructs. If you are react dev, who isolates all components, do not reuse/abuse naming or do not export interfaces/types - it doesn’t matter! Make your linter happy and live peacefully.
The video should be 30 sec “shorts”, where you show the real difference and warn about possible interfaces merge. Nothing more!
When developers try to fit a square peg in a round hole...SMH.
Just learn what the primitives do, then find the appropriate ways to use them. Enough with the bikeshedding.
I default to interface unless I need something more complex, like defining a recursive type or a union type like you've shown.
I would also argue that defining an intersection type consisting of multiple object types is actually easier and more readable to define with an interface than using the type keyword, provided you are not naming your types using letters of the alphabet.
Even thought they work similar for objects they have their very own use cases. You wouldn’t use an interface to define Man-Bear-Pig, you use a type.
I think it is not completed answer because type and interface have I different use cases and it is terrible things that documentation is not restrict use cases for each...
A `type` is only for describing some data structures without behaviour - if we need to transfer data between some logical parts in out app and this object does not have any behaviour - use `type` - simple data container, dto, response/request model, another complex type...
If we need to add some behaviour for our object we need to use `interface` which defines some contract for interaction and could be extended with some inheritance hierarhy... its comes from OOP and in some cases is usefull for FE:
- we want to make services reusable and replacable (mocks for testing)
- service that is used in many places and we want to refactor it - if have interface that was implemented the developer cant change the contract and its mostly means that out app will not fail after refactoring
- all components in any SPA framework is implementing some kind of interface and might be described with it
I think you missed one very important point. In debug when you do types, you never see where the fields come from. If you have a type that combines 5 others, you don't see it in error messages: you see the whole type definition but not what comes from where.
Interfaces in this respect behave more like in Java or C#: you always see which interfaces a class implements and which field comes frome where
Basically complex types combinations (with | or &) basically create a completely new type without remembering where fields came from. Interfaces always remain named entities
Its one of my pet peeves about typescript tbh. Interfaces vs type is a stupid problem we have to face that I wished was not a thing.
Luckily, its not a huuge problem, but still dumb to have to think about vs other typed language’s solutions
Think the last "advantage" of interfaces is a code smell in general. You should not be required to extend external objects and it will break if the interface is renamed on a version update, you are basically coupled to the libraries version if you do this. Maintenance nightmare... And for objects in the own repository you could just create a wrapper or extend the existing attribute.
type cannot be overwritten but you can overwrite interface.. for example use type to model and validate data type in the props of a UI component, so imagine you are bulding e-commerce application you have a customer object from a data base this object has a lot of connections to order object and other objects, and you're in the front-bulding an `order-history` page for the customer, your component will need order history list of specific customer and maybe a links to products in this order list and date or maybe payment method or delviery type now you're infornt of a combination of data types from more than one object, then create a `type` to model and validate the data for your UI component, you can use interface ofcourse but interface meant for customer object itself while type it could be a data in UI props or state.
Types are crap to maintain crappy js compatibility, read sintatic sugar, to please js hardcore, read non realistic codees, devs..ish. Even Crockford is telling us that js must go!
For reason number one, if you need to type something as string, why don't you just type it as string directly? And let's be honest, you can only do this for primitive types anyway, why would you even want to use `type Stype` in the first place? It sounds like creating a problem first and then finding the solution.
The difference between a good coder and a good engineer is knowing when to use your tools properly and not just relying on a single paradigm.
Interfaces for object types and types for typed instances.
Inheritance can only be done with interfaces and helps with conceptually linking your objects. Wouldn't you rather have an interface that extends your shape rather than define a type that has a union of all shapes?
This concept is like always resorting to const objects for your functions to avoid changing "this"
You are confusing your likes with a code smell... only because you like to use something does not mean all the people hace used it. You does not govern reasons to use type, you just explain when you really need to use type (which is the first and second example), and that's all. All your arguments was "I like to use type". There is no differences on almost all the practical cases. You ca use both and you can understand both. There is no code smell.
Most people here defending interfaces have no clue why they are using them lol. Saying that using both interfaces and types is a good practise just because semantically it can make sense (from OOP) is really stupid. If you do something in code just because you think its right without gaining any real advantage, then you are just a bad developer. Using both interfaces and types in a codebase doesn't give you any advantage at all. It's not easier to read a it's not easier to use. Unless for some specific reason you really need to use interface, its always better to use types. There is really no point in mixing those just because someone told you to do so...
pretty much don't agree at all but one part of this seems especially unreasonable and maybe someone can just explain it to me. Why the hell you would like to have in your code something like this "type SType = string"?
Usually i like your videos.
But for this one I'm sorry to say i think you're wrong.
Its not about one being better than the other.
- type is for describing a data structure.
- interface is for describing behavior of an object.
I font get this orange to apples comparison. Types and interfaces have very distinct, different uses. They dont compete.
Aaaaaand another video telling us to not use some specific feature of a language. The arguments are always incomplete and gloss over some advantages of using this feature (here for example Kyle did not mention how useful interfaces are for implementing classes). Even though the reality is kind of boring, it is what it is: IT DEPENDS. But this doesn't generate clicks right? I have used types and interfaces, they both have their use cases.
classes can implement types too...