3 ms·

I am curious, so do you then prefer JS over TS? It still feels to me that you're doing something wrong, and are finding any reason to blame the language. I had

by tekkk 8y ago

I am curious, so do you then prefer JS over TS? It still feels to me that you're doing something wrong, and are finding any reason to blame the language. I had very negative views about TS when I did some hobby project with it was it 3 years ago. I felt it only added confusing boilerplate, that hindered my ability to code. But a lot of it was just my own inexperience with the type system, and I was getting stuck many times because I didn't know how to use it. Now it feels like a breeze and I take shortcuts when I need them, and add the interfaces when it feels necessary. It was a bitter thing to swallow, to admit to myself that I just hadn't understood TS and reverse my views once I got hang of it. Sometimes when you first have a bad experience with well basically anything, you'll be viewing it with the same negative emotion throughout your life. If so many people, experienced and inexperienced developers alike, are saying good things about TS maybe there's something there that you just haven't discovered? >Typescript solves a few small but obvious problems and introduces multiple new problems that are worse but less obvious (it makes the details of the code better, but the foundation worse). Care to elaborate?

jondubois 8y ago
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.

by tekkk 8y ago

jondubois 8y ago

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.