Well, typescript is constantly improving over the years, witch each release you are able to represent more real-world JS patterns and type system is getting mor

Well, typescript is constantly improving over the years, witch each release you are able to represent more real-world JS patterns and type system is getting more strict options. So this 3 points from article might be improved in future. About the point the article makes: 1) I remember when excess property check was introduces I was really happy! Because I remembered bug that would be caught with it. I had some interface with optional properties in common library and I renamed property name. Of course when I updated this library in another project I didn't get any compile errors because this was optional property and now I was just passing some extra property which was ignored. Excess property check would have found it because I was passing object literal. Structural typing is great choice in Typescript because it's basically type-safe duck-typing which is used everywhere in Javascript projects. It's not uncommon to have one component that accept objects with some properties but this object contains many extra properties because it came from different component and these properties are used elsewhere. It's standard pattern in Javascript world. But when your function requires some object of given shape and you are creating this object right now using literal syntax, then it's really likely that you made a mistake. Why create extra properties for just created object when you clearly see they are additional? And I read that Typescript teams is very happy with this feature[0]. However, excess properties check is great but useful only on call side. I cannot say that my function doesn't accept extra parameters. I would really love to get Exact types[1]. Which would allow me to force not having extra parameter in passed object. 2) As mentioned in article, Flow decided to have classes nominally typed. In Typescript everything is structurally typed so it's actually more consistent ;) I really hope we'll get nominal typing and opaque types sometime in future. I read TS team was thinking a lot how to do this. I don't remember what is the current status of this. 3) For me it's more problematic that Typescript doesn't narrow types of an union when you do conditional check. The reason is that in general it is unsound (but I think it would not be if you had only union of Exact types, that's another reason why I would love to have Exact types!). Example in article doesn't have this problem so I guess this could have been improved. Sound like minor issue for me but maybe author could create suggestion on github to improve it and allow discriminator to be nested? [0] https://github.com/Microsoft/TypeScript/issues/12936#issuecomment-284590083 https://github.com/Microsoft/TypeScript/issues/12936#issueco... [1] https://github.com/Microsoft/TypeScript/issues/12936 https://github.com/Microsoft/TypeScript/issues/12936