5 ms·

A 10x Faster TypeScript with Anders Hejlsberg [video]

42 points by vyrotek 1y ago

deleted 1y ago
[deleted]
jasode 1y ago
A previous discussion in March 2025 referencing a shorter video : https://news.ycombinator.com/item?id=43332830 https://news.ycombinator.com/item?id=43332830
anonzzzies 1y ago
It is the compiler, not TS, please change the title. People are already parroting it so damage being done.
- syoleene 1y ago
  It's my understanding that TS is the compiler as TS doesn't get executed as is. Am I wrong?
  - tgv 1y ago
    I suppose the parent means that people will interpret it as the resulting code running 10x faster. Which is not a totally reasonable way of reading it.
    - anonzzzies 1y ago
      That is what I meant.
      - tgv 1y ago
        And I added a not too many. I think it’s a reasonable interpretation.
- evilduck 1y ago
  What possible damage? People outing themselves as ignorant? I don't see the issue, it tells you which parrots to ignore.
- dimitropoulos 1y ago
  you're faulting a headline for being precise and accurate. there is no sense in which TypeScript is a runtime. TypeScript is literally a complier (targeting JavaScript, which has runtimes) and nothing more and has always been as such.
  - owebmaster 1y ago
    being technically accurate while still ambiguous is clickbait.
theThree 1y ago
Good to see there is already a preview version (@typescript/native-preview). Can tsc/ts-node use it now?
MortyWaves 1y ago
I’m imagining a really, really, really rough ride for this. I don’t mean the compiler, tsc CLI, or VS support. I know the TypeScript team will have already competently done their side of the story. I think that as usual, it’s going to be the hellscape ecosystem of Node that is going to be a complete pain here for devs just wanting to use TypeScript. Somehow, the vast myriad of tools and their dependencies, find a way to make writing TS/JS worse while trying to make it better. You’d expect a simple package change to be straightforward, but after ten years of dealing with web tooling ranging from before the webpack era to now, I am constantly amazed by the new ways these tools manage to fuck everything up. I imagine for Deno the change to the new compiler will be seamless and not even noticeable.
- anon7000 1y ago
  It basically depends how deep the other tooling is sticking its claws into TS internals which won’t be accessible in the same way anymore. I’ll bet the two most painless improvements will be: - tsc just for type checking. (A lot of places run tsc just as a type checking step, and avoid type checking during the full build.) - TS language server. By far the worst part of TS for large repos today — in my main monorepo, it consumes like 10GB of RAM and actions like “jump to definition” become so slow that it’s unusable. Things that may be painful: - Integration with 3rd party compilers like webpack which use TSC. Also unsure how tools like Rspack will need to consume tsc, given that they use a highly parallel rust architecture already. - Integration with tools like Jest which need to transpile code before running TS. - Integration with running Node directly — eg swchook or ts-node for bin scripts

42 points by vyrotek 1y ago

deleted 1y ago

[deleted]

A previous discussion in March 2025 referencing a shorter video : https://news.ycombinator.com/item?id=43332830 https://news.ycombinator.com/item?id=43332830

anonzzzies 1y ago

It is the compiler, not TS, please change the title. People are already parroting it so damage being done.

syoleene 1y ago
It's my understanding that TS is the compiler as TS doesn't get executed as is. Am I wrong?
- tgv 1y ago
  I suppose the parent means that people will interpret it as the resulting code running 10x faster. Which is not a totally reasonable way of reading it.
  - anonzzzies 1y ago
    That is what I meant.
    - tgv 1y ago
      And I added a not too many. I think it’s a reasonable interpretation.
evilduck 1y ago
What possible damage? People outing themselves as ignorant? I don't see the issue, it tells you which parrots to ignore.
dimitropoulos 1y ago
you're faulting a headline for being precise and accurate. there is no sense in which TypeScript is a runtime. TypeScript is literally a complier (targeting JavaScript, which has runtimes) and nothing more and has always been as such.
- owebmaster 1y ago
  being technically accurate while still ambiguous is clickbait.

theThree 1y ago

Good to see there is already a preview version (@typescript/native-preview). Can tsc/ts-node use it now?

MortyWaves 1y ago

I’m imagining a really, really, really rough ride for this. I don’t mean the compiler, tsc CLI, or VS support. I know the TypeScript team will have already competently done their side of the story. I think that as usual, it’s going to be the hellscape ecosystem of Node that is going to be a complete pain here for devs just wanting to use TypeScript. Somehow, the vast myriad of tools and their dependencies, find a way to make writing TS/JS worse while trying to make it better. You’d expect a simple package change to be straightforward, but after ten years of dealing with web tooling ranging from before the webpack era to now, I am constantly amazed by the new ways these tools manage to fuck everything up. I imagine for Deno the change to the new compiler will be seamless and not even noticeable.

anon7000 1y ago
It basically depends how deep the other tooling is sticking its claws into TS internals which won’t be accessible in the same way anymore. I’ll bet the two most painless improvements will be: - tsc just for type checking. (A lot of places run tsc just as a type checking step, and avoid type checking during the full build.) - TS language server. By far the worst part of TS for large repos today — in my main monorepo, it consumes like 10GB of RAM and actions like “jump to definition” become so slow that it’s unusable. Things that may be painful: - Integration with 3rd party compilers like webpack which use TSC. Also unsure how tools like Rspack will need to consume tsc, given that they use a highly parallel rust architecture already. - Integration with tools like Jest which need to transpile code before running TS. - Integration with running Node directly — eg swchook or ts-node for bin scripts