4 ms·

CoffeeScript and TypeScript are different enough that I don't think TypeScript could possibly have the same fate. CoffeeScript was all about syntax sugar, but 9

CoffeeScript and TypeScript are different enough that I don't think TypeScript could possibly have the same fate. CoffeeScript was all about syntax sugar, but 95% of the value of TypeScript is the typechecker that runs in your dev environment (editor, CI, etc) and has no business running in the browser. I sure hope we don't get to a world where every browser needs to implement a standards-compliant typechecker; that would be both architecturally questionable and greatly slow down improvements to the type system. It would be nice if the browser could accept and execute TypeScript code (that is, ignore the type annotations), which would avoid the need for a transpile step, but that's a relatively minor improvement, and would certainly not be a replacement for TypeScript itself.

yazaddaruvala 8y ago
FWIW, “the browser” already type checks Javascript. Where a compiler would throw an exception, the Javascript runtime creates/destroys optimizations. For example, ‘1 + a’ type checks ‘a’ and optimizes the assembly if ‘a’ is a number. As soon as there is some other type represented by ‘a’ the runtime deoptimizes that method. If the runtime could just throw an exception in those situations and keep the typed optimization a lot of our Javascript might run faster.
- alangpierce 8y ago
  Browsers certainly collect runtime types of variables in hot code paths, but that's pretty different from the whole-program static verification that TypeScript does. TypeScript is designed to have an expressive and flexible type system, and typechecking a large codebase might take tens of seconds or minutes, not something you want running every time any user loads your site. That said, including types in JS could be useful as a hint for the optimizer, but at least in TypeScript and Flow, the types can always be wrong even if no errors are reported (e.g. from misuse of escape hatches), so the runtime would need to double-check them.
  - yazaddaruvala 8y ago
    I agree with you. They definitely should keep doing "type checking" lazily. From what I understand, it would be a lot cheaper if types were built into the language, and the runtime's contract could trust the type and if it is wrong then undefined behavior occurs.

yazaddaruvala 8y ago

FWIW, “the browser” already type checks Javascript. Where a compiler would throw an exception, the Javascript runtime creates/destroys optimizations. For example, ‘1 + a’ type checks ‘a’ and optimizes the assembly if ‘a’ is a number. As soon as there is some other type represented by ‘a’ the runtime deoptimizes that method. If the runtime could just throw an exception in those situations and keep the typed optimization a lot of our Javascript might run faster.

alangpierce 8y ago
Browsers certainly collect runtime types of variables in hot code paths, but that's pretty different from the whole-program static verification that TypeScript does. TypeScript is designed to have an expressive and flexible type system, and typechecking a large codebase might take tens of seconds or minutes, not something you want running every time any user loads your site. That said, including types in JS could be useful as a hint for the optimizer, but at least in TypeScript and Flow, the types can always be wrong even if no errors are reported (e.g. from misuse of escape hatches), so the runtime would need to double-check them.
- yazaddaruvala 8y ago
  I agree with you. They definitely should keep doing "type checking" lazily. From what I understand, it would be a lot cheaper if types were built into the language, and the runtime's contract could trust the type and if it is wrong then undefined behavior occurs.