4 ms·

IMO, until TypeScript gets the following features, it's not worth using: - Native TypeScript runtime interpreter in Deno (TypeScript alternative to Node.js).

IMO, until TypeScript gets the following features, it's not worth using: - Native TypeScript runtime interpreter in Deno (TypeScript alternative to Node.js). - Native TypeScript runtime interpreter in all major browsers. - At least 20% performance improvement over plain JavaScript. The build step has to go away because: - Source maps are unreliable, bulky, slow and add too much complexity for some environments; many environments fail at using them correctly and this can make it difficult to debug code. Being forced to debug ugly transpiled JavaScript is unacceptable and should never happen. - It's slow to work with. TypeScript often claims to be 'scalable' but reality is that large projects often take multiple minutes to build for every change. There are no good incremental build solutions which also do proper type checking. There is no runtime type checking. Native browser support is also essential. The bundling step makes in infeasible to freely mix and match modules written in the two languages in a way which is debuggable. Microsoft should look into Adobe Flash's ActionScript 3 migration from ActionScript 2 for inspiration (both based on ECMAScript spec BTW, just like JavaScript/TypeScript). I remember ActionScript 3 clearly because it was able to deliver a 40% speedup AND runtime type checking... In spite of these huge benefits, I remember that some developers were still hesitant to switch to ActionScript 3! This new generation of developers has clearly lost its ability for critical thinking - I find the current complete lack of resistance to TS is very strange. There are a lot more reasons to resist JS to TS migration compared to AS2 to AS3 migration. I remember in AS2, most people were not declaring types in their code (even though there was support for compile-time type checking). Only in AS3 people started adding Type annotations to their code.

azangru 6y ago
> IMO, until TypeScript gets the following features, it's absolutely not worth using That doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; whereas meanwhile typescript offers huge benefits compared to untyped javascript when it comes to large codebases and refactorings.
- cryptica 6y ago
  >> 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...
wereHamster 6y ago
> - At least 20% performance improvement over plain JavaScript. How would that work? TS is not an optimizing compiler, it's only a type checker.
- cryptica 6y ago
  Well ActionScript 3 got it to 40% thanks to static type performance optimizations. They did rewrite the engine. That's what it takes unfortunately. The fact that Microsoft does not want to hire serious compiler engineers and prefers to spend all the money on marketing is not my fault.
  - benschulz 6y ago
    You do realize that Anders Hejlsberg is on the TypeScript team? I don't want to imply that he's superhuman or anything, but.. just what is your idea of "serious compiler engineers"?
    - cryptica 6y ago
      Well maybe he doesn't get enough leeway. Maybe he knows that he should be building an engine from scratch but management won't let him. This is very common in companies of that size.
      - int_19h 6y ago
        Hejlsberg already designed a language with its own runtime from scratch - that was C#.
  - Jasper_ 6y ago
    ActionScript 3 got a huge improvement because they added a JIT. AVM1 was an interpreter, and a very infamously bad one at that.
  - dwaite 6y ago
    It is hopefully apparent that the 40% increase (whether it was meant to indicate over leading Javascript engines at the time or over the ActionScript 2 engine) does not in any way indicate there is headroom for a 40% performance increase if static type performance optimizations were applied to a modern Javascript engine. Many performance improvements come from being able to do code analysis during generation, which is already a trade-off for environments doing in-time interpretation, code generation and optimization. Large performance increases would most come from removing dynamic language complexity, such as having use of the 'class' feature added in ECMAScript create non-mutable properties by default for function declarations.
cvlasdkv 6y ago
I've seen well over 20% improvement in developer velocity which is far more important than performance in most businesses
- cryptica 6y ago
  I've also seen 20% improvement with TypeScript when working with developers in a big corporate environment (especially when no one cares about the project and everyone gets paid hourly). But when working with senior developers on open source projects (when people don't get paid), I've seen at least 50% drop in developer velocity using TypeScript and lower code quality. My theory is that developers who are passionate about coding don't need TypeScript to produce high quality code. It mostly just takes the fun out of it. But I guess if there is no passion to begin with, then I can see how TypeScript can't hurt in that respect. I've worked for a company like this once for 6 months; I had to quit because I enjoy coding too much to spend most of my time writing and renaming type definitions and waiting for the compiler.
  - SaxonRobber 6y ago
    Imagine believing this
    - pillowwizard 6y ago
      Most of us hold many opinions that we've formed without any reflection. More like: Imagine being passionate enough about something to complain about it online, while not even bothering to think it through.
mekster 6y ago
You're missing the point of using TypeScript. How does having native (as in internally having the transpiler embedded) in deno make you suddenly use TS one day? You can use ts-node. How long do you think all the browsers would agree that TS would totally be the future of JS and implement it natively, let alone wait until everyone out there to start using such browsers that non TS supporting browsers are almost all eliminated for them to be ignored? There's a reason TS can be compiled down to ES5. And why are you asking TS for performance over raw JS? Seems off topic from TS' point of view. TS and JS use same principle in the runtime environment and not sure how TS can suddenly beat JS by a good margin. A project that needs multiple minutes for every change sounds like you're doing it wrong. Split the code or use ts-node? And you want to throw away all the benefits of TS until all of the above which I don't really feel are required are solved? I don't see why.

azangru 6y ago

> IMO, until TypeScript gets the following features, it's absolutely not worth using That doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; whereas meanwhile typescript offers huge benefits compared to untyped javascript when it comes to large codebases and refactorings.

cryptica 6y ago
>> 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...

wereHamster 6y ago

> - At least 20% performance improvement over plain JavaScript. How would that work? TS is not an optimizing compiler, it's only a type checker.

cryptica 6y ago
Well ActionScript 3 got it to 40% thanks to static type performance optimizations. They did rewrite the engine. That's what it takes unfortunately. The fact that Microsoft does not want to hire serious compiler engineers and prefers to spend all the money on marketing is not my fault.
- benschulz 6y ago
  You do realize that Anders Hejlsberg is on the TypeScript team? I don't want to imply that he's superhuman or anything, but.. just what is your idea of "serious compiler engineers"?
  - cryptica 6y ago
    Well maybe he doesn't get enough leeway. Maybe he knows that he should be building an engine from scratch but management won't let him. This is very common in companies of that size.
    - int_19h 6y ago
      Hejlsberg already designed a language with its own runtime from scratch - that was C#.
- Jasper_ 6y ago
  ActionScript 3 got a huge improvement because they added a JIT. AVM1 was an interpreter, and a very infamously bad one at that.
- dwaite 6y ago
  It is hopefully apparent that the 40% increase (whether it was meant to indicate over leading Javascript engines at the time or over the ActionScript 2 engine) does not in any way indicate there is headroom for a 40% performance increase if static type performance optimizations were applied to a modern Javascript engine. Many performance improvements come from being able to do code analysis during generation, which is already a trade-off for environments doing in-time interpretation, code generation and optimization. Large performance increases would most come from removing dynamic language complexity, such as having use of the 'class' feature added in ECMAScript create non-mutable properties by default for function declarations.

cvlasdkv 6y ago

I've seen well over 20% improvement in developer velocity which is far more important than performance in most businesses

cryptica 6y ago
I've also seen 20% improvement with TypeScript when working with developers in a big corporate environment (especially when no one cares about the project and everyone gets paid hourly). But when working with senior developers on open source projects (when people don't get paid), I've seen at least 50% drop in developer velocity using TypeScript and lower code quality. My theory is that developers who are passionate about coding don't need TypeScript to produce high quality code. It mostly just takes the fun out of it. But I guess if there is no passion to begin with, then I can see how TypeScript can't hurt in that respect. I've worked for a company like this once for 6 months; I had to quit because I enjoy coding too much to spend most of my time writing and renaming type definitions and waiting for the compiler.
- SaxonRobber 6y ago
  Imagine believing this
  - pillowwizard 6y ago
    Most of us hold many opinions that we've formed without any reflection. More like: Imagine being passionate enough about something to complain about it online, while not even bothering to think it through.

mekster 6y ago

You're missing the point of using TypeScript. How does having native (as in internally having the transpiler embedded) in deno make you suddenly use TS one day? You can use ts-node. How long do you think all the browsers would agree that TS would totally be the future of JS and implement it natively, let alone wait until everyone out there to start using such browsers that non TS supporting browsers are almost all eliminated for them to be ignored? There's a reason TS can be compiled down to ES5. And why are you asking TS for performance over raw JS? Seems off topic from TS' point of view. TS and JS use same principle in the runtime environment and not sure how TS can suddenly beat JS by a good margin. A project that needs multiple minutes for every change sounds like you're doing it wrong. Split the code or use ts-node? And you want to throw away all the benefits of TS until all of the above which I don't really feel are required are solved? I don't see why.