5 ms·

>> that doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; It's not my fault that browsers are not going to

>> that doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; It's not my fault that browsers are not going to do it. It doesn't change the fact that it is necessary and that TS is useless without it (the cons outweigh the pros). >> huge benefits compared to untyped javascript when it comes to large codebases and refactorings I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can provide another argument against this: TypeScript only protects the code from compile time type mismatches, it does not prevent every other possible kind of error; it does not even protect the code from runtime type mismatches (for example from JSON objects passed in an HTTP or RPC request). It also does not protect from race conditions, memory leaks, issues with multiple sources of truth, unexpected asynchronous state mutations, poor choice of abstractions, poor encapsulation of state changes, poorly handled runtime exceptions, poorly handled runtime schema validation errors, bidirectional data flow issues (which lead to glitchy state changes and infinite loops), poor choice of ADTs which lead to inefficient code, poor choice of libraries for the use case, misuse of common programming patterns, and any other major logic errors... At best, it projects code from only 5% of all possible bugs; typically the simplest, most obvious kinds of bugs. Please think about this objectively. TS adds value, but very little value and also it takes away value in other ways. For the really difficult runtime bugs which take serious debug time, it adds no value; it makes debugging harder because of its reliance on source mapping. And by the way, instead of down-voting, please try to convince me otherwise because I'm really suffering with the new TS-first reality (I'm on the losing side). I really do want to see the light but I'm not seeing it at all. I'm seeing masses of people running towards a cliff. I know there is a cliff there because I pulled myself out of it (learned the hard way) and have been walking in the opposite direction for the past few years and I don't see why I should go back there simply because that's the direction where all the cool people are heading.

azangru 6y ago
> I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can share anecdotal data about my own experience while refactoring: I do rely on the type checker (be it Flow or TypeScript) to alert me when my code changes have introduced type errors. Every time I run the type checker I realise that it would have taken me ages to read through my code and hunt down the type mismatches that might have been introduced. I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript [0] > TypeScript ... does not Sure. It's not perfect. It's not Haskell, or PureScript, or Scala, or OCaml. But it does protect you from some of the errors. Protection from some of the errors is better than no protection at all, that's my opinion. As a bonus point, type annotations serve as a living documentation of your code. > instead of down-voting, please try to convince me otherwise I did not downvote your post. I do not downvote other people's posts. [0] - https://twitter.com/remohjansen/status/1093815648566894594?lang=en https://twitter.com/remohjansen/status/1093815648566894594?l...
- cryptica 6y ago
  >> I can share anecdotal data about my own experience while refactoring I totally understand what you're talking about here. I know that TS feeling of being able to just tell the IDE to rename that variable or type anywhere and have that change automatically applied everywhere in the whole codebase. That said, my anecdotal data (having gone back and forth between first AS2 and AS3 for several years and then later between JS and TS multiple times over many years) is that good tests (especially integration tests) even with modest coverage are equally good at finding these sorts of bugs. If I forgot to rename a variable, my tests will fail straight away. Also, usually I try to keep my classes and functions localized with well defined responsibilities so that any specific kind of data does not need to traverse too many different files; that makes refactoring a lot easier. IMO, not using TS puts more pressure on me to design code in this way and this design approach yields many other benefits. It takes encapsulation to another level. For example, I don't even believe in the idea of 'cross-cutting concerns' anymore (which is central to the Dependency Injection pattern). For me, the idea of cross-cutting concerns implies a violation of the separation of concern principle (a violation of the cross-cutting kind to be exact). There are almost always ways to avoid these in your code and doing so is always worth it if the programming environment allows it. >> I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript I did read that article when it came out but my point of view on this is that if mostly the same developers rewrite a project (even if they did so in the same language), I would expect at least 40% to 50% fewer bugs. I don't think TypeScript should get the credit there. The reality is that people learn from their mistakes so if they rewrite something, it's going to be better the next time round.
matchbok 6y ago
None of those issues are what TS tries to solve. At all. Compile-time checking is well worth the switch. Refactoring old JS express apps is a nightmare. You can add TS incrementally, so your argument about "downsides" is not valid. You can use it as strictly as you'd like.
- cryptica 6y ago
  >> None of those issues are what TS tries to solve. At all. That is exactly my point. My argument then follows that that these are in fact the most important issues and that they dwarf all other possible issues; not only in terms of being the most difficult ones to debug but also the most common ones. My argument is then that the problems which TypeScript does solve are so insignificant in the grand scheme of things that it's simply not worth it. Like putting lipstick on a pig.

azangru 6y ago

> I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can share anecdotal data about my own experience while refactoring: I do rely on the type checker (be it Flow or TypeScript) to alert me when my code changes have introduced type errors. Every time I run the type checker I realise that it would have taken me ages to read through my code and hunt down the type mismatches that might have been introduced. I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript [0] > TypeScript ... does not Sure. It's not perfect. It's not Haskell, or PureScript, or Scala, or OCaml. But it does protect you from some of the errors. Protection from some of the errors is better than no protection at all, that's my opinion. As a bonus point, type annotations serve as a living documentation of your code. > instead of down-voting, please try to convince me otherwise I did not downvote your post. I do not downvote other people's posts. [0] - https://twitter.com/remohjansen/status/1093815648566894594?lang=en https://twitter.com/remohjansen/status/1093815648566894594?l...

cryptica 6y ago
>> I can share anecdotal data about my own experience while refactoring I totally understand what you're talking about here. I know that TS feeling of being able to just tell the IDE to rename that variable or type anywhere and have that change automatically applied everywhere in the whole codebase. That said, my anecdotal data (having gone back and forth between first AS2 and AS3 for several years and then later between JS and TS multiple times over many years) is that good tests (especially integration tests) even with modest coverage are equally good at finding these sorts of bugs. If I forgot to rename a variable, my tests will fail straight away. Also, usually I try to keep my classes and functions localized with well defined responsibilities so that any specific kind of data does not need to traverse too many different files; that makes refactoring a lot easier. IMO, not using TS puts more pressure on me to design code in this way and this design approach yields many other benefits. It takes encapsulation to another level. For example, I don't even believe in the idea of 'cross-cutting concerns' anymore (which is central to the Dependency Injection pattern). For me, the idea of cross-cutting concerns implies a violation of the separation of concern principle (a violation of the cross-cutting kind to be exact). There are almost always ways to avoid these in your code and doing so is always worth it if the programming environment allows it. >> I can also point you to the famous AirBnB's slide, which says that they estimate that around 40% of their bugs can be prevented with TypeScript I did read that article when it came out but my point of view on this is that if mostly the same developers rewrite a project (even if they did so in the same language), I would expect at least 40% to 50% fewer bugs. I don't think TypeScript should get the credit there. The reality is that people learn from their mistakes so if they rewrite something, it's going to be better the next time round.

matchbok 6y ago

None of those issues are what TS tries to solve. At all. Compile-time checking is well worth the switch. Refactoring old JS express apps is a nightmare. You can add TS incrementally, so your argument about "downsides" is not valid. You can use it as strictly as you'd like.

cryptica 6y ago
>> None of those issues are what TS tries to solve. At all. That is exactly my point. My argument then follows that that these are in fact the most important issues and that they dwarf all other possible issues; not only in terms of being the most difficult ones to debug but also the most common ones. My argument is then that the problems which TypeScript does solve are so insignificant in the grand scheme of things that it's simply not worth it. Like putting lipstick on a pig.