7 ms·

These days, TypeScript is effectively nothing more than a high-powered linter. The performance of this linter is so bad that we need to structure our code in a

These days, TypeScript is effectively nothing more than a high-powered linter. The performance of this linter is so bad that we need to structure our code in a specific way so that we can still afford to run the linter. Of the performance tips at the end, the interface vs. intersection type one is the suggestion I find the most annoying. That’s because it’s the most common pattern, and using interfaces is conceptually a lot less clean. It’s terrible that a linter effectively forces you into writing worse code. I really wish the TypeScript team got their act together and fixed the performance of their linter somehow. Finding clever optimizations, porting to Go/Rust, whatever is necessary. (3rd-party reimplementations won’t do: they’ll never catch up with a corporate-funded moving target.)

seanmcdirmid 2y ago
Doesn’t the type checker have to run in JavaScript to fit into VS code? A C# implementation would be much faster, no need to go native with C++/Rust (not sure speed in Go would really compete). The big issue is dealing with a structural highly expressive type system, the language of implementation is only going to be a constant slow down (but that constant can be large).
- mook 2y ago
  Don't a lot of the linters run externally via language servers? I'm pretty sure the rust linters are rust-native for example.
- Quothling 2y ago
  It depends on which typescript toolset you use, but generally speaking you're probably riding on mix of C++ and Javascript if you're using VSC. VSC itself uses C++ in it's core components since that is how electron works. Similarly the language server and tooling for both Typescript and Node are build with C++. If you're fancy and use Bun you're running on Zig. Eslint itself runs on Javascript, but the parser it uses feeds it something called an abstract syntax tree, and different parsers will do this differently. So the relatively simple answer would be no, it would not be faster with C# (or Go which would likely have a similar speed to C#).
  - seanmcdirmid 2y ago
    C# should be faster than JavaScript, at least, given all the optimization Microsoft puts into the CLR. But it might not be super portable. I’ve never seen the typescript type checker before, but I wouldn’t be surprised if it were in typescript, which is common as these things go.
    - troupo 2y ago
      > But it might not be super portable. .net is available on all systems where developers work with their code.
      - frenchy 2y ago
        But the popular tooling for it (e.g. Visual Studio), isn't.
        troupo 2y ago
        Visual Studio Code is available for Linux and MacOS. As is Rider.
rtpg 2y ago
Complicated types are effectively little Prolog programs, doing a bunch of very useful and helpful checks to make sure that your code does what you expect it to. I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types, especially when you then use it to create the partially valid types by resolving to never). But I think it would also be very helpful to get people to understand that your types are their own little program that run and have performance characteristics. It's not magic! There's been some handwaving about performance not being due to it running in JS (because at the end of the day unification is unification is unification and it takes time), but looking at the Typescript codebase in general and poking at it, I can't help but wonder how much of even the heavier stuff is "death by 1000 cuts" on that front.
- vmfunction 2y ago
  > I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types Maybe give https://gcanti.github.io/fp-ts/ https://gcanti.github.io/fp-ts/ a go?
  - rtpg 2y ago
    I use fp.ts quite a lot! I think it's _extremely unfortunate_ that the API docs don't include top-level examples for basically anything, though. So when people hit a problem that fp-ts or io-ts can solve, I have to basically write a disclaimer about the slight impenetrability before suggesting it. I really think that TS itself should offer syntax more or less matching what that lib does at the type level, but this is a bit of a maximalist request.
    - epolanski 2y ago
      effect-ts is nowadays the de facto successor of fp-ts and has better docs. As for fp-ts all APIs have examples/tests that show their usage.
      - 2y ago
Narhem 2y ago
If I had to guess working with parsing xml is more complicated than traditional code. Can’t find the links but one of the reasons I’ve seen people move away from xml has been due to the speed in parsing when compared to json or csv.
rafaelmn 2y ago
> These days, TypeScript is effectively nothing more than a high-powered linter. That's a bad take - typescript enables tooling like refactoring/navigation/completion that goes far above a linter. Development tools are just better with typescript vs JS.
- adamc 2y ago
  That's ignoring all the negative effects of using typescript.
  - munbun 2y ago
    The only thing you’ve listed was your preference for readability
    - adamc 2y ago
      True, I did not enumerate them. Adds another step to development and generally adds complexity would be other perceived downsides. I'll note that most of the upsides are also subjective.
      - shepherdjerred 2y ago
        Deno/bun support TS natively, and Node is also adding support. https://github.com/nodejs/node/pull/53725 https://github.com/nodejs/node/pull/53725
      - zarzavat 2y ago
        > adds another step to development I never understood this. It takes maybe 10 minutes to set up TypeScript in a project if you’ve done it before. Compared to all the other times involved (time to learn typescript, time saved debugging and writing tests for type errors) the setup time is a total non-issue.
  - rafaelmn 2y ago
    I was refuting the part about typescript (language and the implementation/language server) being a glorified lint - the value proposition is way higher than that. Even other dynamic languages started moving in this direction due to the benefits of having type annotations brings to tooling/development experience overall.
k__ 2y ago
Technically, it is more than a linter, as enums don't have a direct representation in JS.
bluepnume 2y ago
At this point TS is a turing complete language. Complaining that you have to tune it for performance is like complaining that your runtime code isn't automatically maximally performant without a little tuning.
- shepherdjerred 2y ago
  TypeScript has been turing complete for a very long time. You might find this interesting: https://github.com/type-challenges/type-challenges https://github.com/type-challenges/type-challenges
epolanski 2y ago
What's the alternative? Anything you name has either less support or different cons.
- mdhb 2y ago
  With WASM starting to become a thing we are no longer limited to just JavaScript and things that compile to or transpile to JavaScript. It’s early days there but with the JS ecosystem being the mess that it is I’m actively interested in finding alternatives to at least evaluate. One approach I’m enjoying so far is Dart which has two relevant compilers (I.e Dart to JS and Dart to WASM) but they have the advantage that you can just use Dart like normal which is a clear 10x improvement over writing either JS or TS and you only have to worry about the specific layers where you need to interop with JS code and you can wrap that up in really nice ways. For example here’s an example of Dart interacting with browser APIs: https://github.com/dart-lang/web/blob/main/example/example.dart https://github.com/dart-lang/web/blob/main/example/example.d...
- Quothling 2y ago
  You can use something like JSDoc and achieve basically the same thing, but it's very likely that your developer experience will be way worse as you sort of point out. If you're a VSC enjoyer your tooling will be absolutely horrible compared to the Typescript tooling. We use Typescript as our general JavaScript "language" but most of our internal libraries are written in actual JavaScript for performance reasons. They key difference is those libraries are worked on by far fewer people.
  - evilduck 2y ago
    My gut reactions would be to still do whatever performance-related weirdness was absolutely required in a Typescript codebase and either alter the .tsconfig to allow for that project's required style, or to explicitly ts-ignore and type cast the output of the hand-tuned performance code while still maintaining type checking surrounding it so I could still easily produce typedefs for consumers. Even keeping TSC as a type checker while dropping it as a compiler would have been on my list of options before eschewing TSC entirely. I'm not here to challenge your decisions, but there's a real dearth of information on this topic and knowing when something applies to your situation is hard. Someone writing a web server has different problems and concerns than someone writing React or Vue websites, or someone processing IO on a microcontroller. Can you go into some details about your situational how and why? I'm curious to hear more about the nature of these pure-JS-for-performance libs and what was measured as non-performant in the TSC output?
xboxnolifes 2y ago
With such a broad definition of linter, wouldn't the type systems of all statically typed languages just be high-powered linters?
- codeflo 2y ago
  No, in most static languages, the type system influences code generation.
- zachrose 2y ago
  I’ve worked on several TS projects that don’t type check but still “compile” (emit non-TS JavaScript). To me that’s the difference between a linter and a compiler, and I wish those projects had stopped compiling when they could no longer type check.
  - scotttrinh 2y ago
    Good news! There is a configuration option for that: https://www.typescriptlang.org/tsconfig/#noEmitOnError https://www.typescriptlang.org/tsconfig/#noEmitOnError
bk496 2y ago
There is a new type checker called Ezno that is written in Rust and is a lot faster [1]. I have been tracking PRs like [2] that change the definitions to better be optimised by V8. But the effects are only ~30% and not the 50x that might be achievable by native. [1]: https://github.com/kaleidawave/ezno/actions/runs/10299707325 https://github.com/kaleidawave/ezno/actions/runs/10299707325 [2]: https://github.com/microsoft/TypeScript/pull/58928 https://github.com/microsoft/TypeScript/pull/58928
- IshKebab 2y ago
  How fast does tsc process that input though? I would be very surprised if you can get to 50x faster - that's Python territory and JavaScript isn't that slow. 10x maybe?

seanmcdirmid 2y ago

Doesn’t the type checker have to run in JavaScript to fit into VS code? A C# implementation would be much faster, no need to go native with C++/Rust (not sure speed in Go would really compete). The big issue is dealing with a structural highly expressive type system, the language of implementation is only going to be a constant slow down (but that constant can be large).

mook 2y ago
Don't a lot of the linters run externally via language servers? I'm pretty sure the rust linters are rust-native for example.
Quothling 2y ago
It depends on which typescript toolset you use, but generally speaking you're probably riding on mix of C++ and Javascript if you're using VSC. VSC itself uses C++ in it's core components since that is how electron works. Similarly the language server and tooling for both Typescript and Node are build with C++. If you're fancy and use Bun you're running on Zig. Eslint itself runs on Javascript, but the parser it uses feeds it something called an abstract syntax tree, and different parsers will do this differently. So the relatively simple answer would be no, it would not be faster with C# (or Go which would likely have a similar speed to C#).
- seanmcdirmid 2y ago
  C# should be faster than JavaScript, at least, given all the optimization Microsoft puts into the CLR. But it might not be super portable. I’ve never seen the typescript type checker before, but I wouldn’t be surprised if it were in typescript, which is common as these things go.
  - troupo 2y ago
    > But it might not be super portable. .net is available on all systems where developers work with their code.
    - frenchy 2y ago
      But the popular tooling for it (e.g. Visual Studio), isn't.
      - troupo 2y ago
        Visual Studio Code is available for Linux and MacOS. As is Rider.

rtpg 2y ago

Complicated types are effectively little Prolog programs, doing a bunch of very useful and helpful checks to make sure that your code does what you expect it to. I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types, especially when you then use it to create the partially valid types by resolving to never). But I think it would also be very helpful to get people to understand that your types are their own little program that run and have performance characteristics. It's not magic! There's been some handwaving about performance not being due to it running in JS (because at the end of the day unification is unification is unification and it takes time), but looking at the Typescript codebase in general and poking at it, I can't help but wonder how much of even the heavier stuff is "death by 1000 cuts" on that front.

vmfunction 2y ago
> I do wish that Typescript would offer some tools to make it more ergonomic to write performant unifying code (I kind of despise conditional types Maybe give https://gcanti.github.io/fp-ts/ https://gcanti.github.io/fp-ts/ a go?
- rtpg 2y ago
  I use fp.ts quite a lot! I think it's _extremely unfortunate_ that the API docs don't include top-level examples for basically anything, though. So when people hit a problem that fp-ts or io-ts can solve, I have to basically write a disclaimer about the slight impenetrability before suggesting it. I really think that TS itself should offer syntax more or less matching what that lib does at the type level, but this is a bit of a maximalist request.
  - epolanski 2y ago
    effect-ts is nowadays the de facto successor of fp-ts and has better docs. As for fp-ts all APIs have examples/tests that show their usage.
    - 2y ago

Narhem 2y ago

If I had to guess working with parsing xml is more complicated than traditional code. Can’t find the links but one of the reasons I’ve seen people move away from xml has been due to the speed in parsing when compared to json or csv.

rafaelmn 2y ago

> These days, TypeScript is effectively nothing more than a high-powered linter. That's a bad take - typescript enables tooling like refactoring/navigation/completion that goes far above a linter. Development tools are just better with typescript vs JS.

adamc 2y ago
That's ignoring all the negative effects of using typescript.
- munbun 2y ago
  The only thing you’ve listed was your preference for readability
  - adamc 2y ago
    True, I did not enumerate them. Adds another step to development and generally adds complexity would be other perceived downsides. I'll note that most of the upsides are also subjective.
    - shepherdjerred 2y ago
      Deno/bun support TS natively, and Node is also adding support. https://github.com/nodejs/node/pull/53725 https://github.com/nodejs/node/pull/53725
    - zarzavat 2y ago
      > adds another step to development I never understood this. It takes maybe 10 minutes to set up TypeScript in a project if you’ve done it before. Compared to all the other times involved (time to learn typescript, time saved debugging and writing tests for type errors) the setup time is a total non-issue.
- rafaelmn 2y ago
  I was refuting the part about typescript (language and the implementation/language server) being a glorified lint - the value proposition is way higher than that. Even other dynamic languages started moving in this direction due to the benefits of having type annotations brings to tooling/development experience overall.

k__ 2y ago

Technically, it is more than a linter, as enums don't have a direct representation in JS.

bluepnume 2y ago

At this point TS is a turing complete language. Complaining that you have to tune it for performance is like complaining that your runtime code isn't automatically maximally performant without a little tuning.

shepherdjerred 2y ago
TypeScript has been turing complete for a very long time. You might find this interesting: https://github.com/type-challenges/type-challenges https://github.com/type-challenges/type-challenges

epolanski 2y ago

What's the alternative? Anything you name has either less support or different cons.

mdhb 2y ago
With WASM starting to become a thing we are no longer limited to just JavaScript and things that compile to or transpile to JavaScript. It’s early days there but with the JS ecosystem being the mess that it is I’m actively interested in finding alternatives to at least evaluate. One approach I’m enjoying so far is Dart which has two relevant compilers (I.e Dart to JS and Dart to WASM) but they have the advantage that you can just use Dart like normal which is a clear 10x improvement over writing either JS or TS and you only have to worry about the specific layers where you need to interop with JS code and you can wrap that up in really nice ways. For example here’s an example of Dart interacting with browser APIs: https://github.com/dart-lang/web/blob/main/example/example.dart https://github.com/dart-lang/web/blob/main/example/example.d...
Quothling 2y ago
You can use something like JSDoc and achieve basically the same thing, but it's very likely that your developer experience will be way worse as you sort of point out. If you're a VSC enjoyer your tooling will be absolutely horrible compared to the Typescript tooling. We use Typescript as our general JavaScript "language" but most of our internal libraries are written in actual JavaScript for performance reasons. They key difference is those libraries are worked on by far fewer people.
- evilduck 2y ago
  My gut reactions would be to still do whatever performance-related weirdness was absolutely required in a Typescript codebase and either alter the .tsconfig to allow for that project's required style, or to explicitly ts-ignore and type cast the output of the hand-tuned performance code while still maintaining type checking surrounding it so I could still easily produce typedefs for consumers. Even keeping TSC as a type checker while dropping it as a compiler would have been on my list of options before eschewing TSC entirely. I'm not here to challenge your decisions, but there's a real dearth of information on this topic and knowing when something applies to your situation is hard. Someone writing a web server has different problems and concerns than someone writing React or Vue websites, or someone processing IO on a microcontroller. Can you go into some details about your situational how and why? I'm curious to hear more about the nature of these pure-JS-for-performance libs and what was measured as non-performant in the TSC output?

xboxnolifes 2y ago

With such a broad definition of linter, wouldn't the type systems of all statically typed languages just be high-powered linters?

codeflo 2y ago
No, in most static languages, the type system influences code generation.
zachrose 2y ago
I’ve worked on several TS projects that don’t type check but still “compile” (emit non-TS JavaScript). To me that’s the difference between a linter and a compiler, and I wish those projects had stopped compiling when they could no longer type check.
- scotttrinh 2y ago
  Good news! There is a configuration option for that: https://www.typescriptlang.org/tsconfig/#noEmitOnError https://www.typescriptlang.org/tsconfig/#noEmitOnError

bk496 2y ago

There is a new type checker called Ezno that is written in Rust and is a lot faster [1]. I have been tracking PRs like [2] that change the definitions to better be optimised by V8. But the effects are only ~30% and not the 50x that might be achievable by native. [1]: https://github.com/kaleidawave/ezno/actions/runs/10299707325 https://github.com/kaleidawave/ezno/actions/runs/10299707325 [2]: https://github.com/microsoft/TypeScript/pull/58928 https://github.com/microsoft/TypeScript/pull/58928

IshKebab 2y ago
How fast does tsc process that input though? I would be very surprised if you can get to 50x faster - that's Python territory and JavaScript isn't that slow. 10x maybe?