4 ms·

I started coding with ActionScript 2 and then switched to ActionScript 3 (ECMAScript with types; basically the same as TypeScript) for years starting at a very

I started coding with ActionScript 2 and then switched to ActionScript 3 (ECMAScript with types; basically the same as TypeScript) for years starting at a very early age. Then I did Java and C++ while at uni. Then I used JavaScript for several years (and did some half year stints with TypeScript in between) so I have a more balanced experience with both statically and dynamically typed languages than the vast majority of developers (I have over 15 years of experience in total: Slightly more with dynamically typed languages). I also maintain several open source projects in my own time so I work many hours per week. Also, I'm currently working on a TypeScript project (second time in the past 2 years). Also, I've spoken to several very senior developers (including some influential individuals) who also have broad experience and who share my point of view. So that's why I feel confident when I say that TypeScript does not add any actual safety. I don't have skin on either side (well actually my current employer uses TypeScript so saying bad things about TypeScript does not align with my career interests) and I really did give both a really fair, thorough trial with an open mind. As I said, I even switched back and forth between them for extended periods to gain more perspective. 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 overall foundation and the process worse).

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.

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.