Some problems with TypeScript: - Discourages using external libraries because of type name conflicts. Interface and class names must be universal so if two lib

Some problems with TypeScript: - Discourages using external libraries because of type name conflicts. Interface and class names must be universal so if two libraries use the same name for different types, then that makes things difficult. It's also a problem if two libraries use different type names to represent the same concept. This encourages developers to reinvent the wheel as opposed to relying on battle-tested external libraries. There is a workaround for name conflicts but it's not ideal. - Type definitions of third party modules are likely to be or to become out of date. - In terms of code foundation; the way all the logic fits together in TypeScript is rigid and tightly interlocked around arbitrary labels (type names) that developers have invented (and each developer tends to have a different idea about the meaning and use cases of each type). As project requirements evolve, the underlying logic starts to diverge from the meaning of the labels to the point that they lose their meaning completely. Most large TypeScript projects end up with many types that have slightly different meanings but are meant to be used in different ways and impose different constraints on developers (e.g. User, UserInfo, UserConfig, Account, UserAccount, ReadonlyUser...). You might say that this could be avoided by good programming patterns, but if you look at most large popular TypeScript projects, you will see a lot of strangely named types which only make sense to developers who have been working on the project for a long time.