TypeScript team released an explorer for performance tuning

https://devblogs.microsoft.com/typescript/introducing-deopt-explorer/

by aabbcc1241 • 3 years ago

111 41 3 years ago

devblogs.microsoft.com

muglug4• 3 years ago

This is really impressive work, which can benefit other large JS tools.

I realise this is sort of a dead horse, but rewriting the Typescript checker in Rust would not be an impossible task for a team as well-resourced as Microsoft’s.

I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year.

It would speed up the TypeScript typechecker at least 3-5x, which would save a lot of programmer time (and also datacenter energy consumption).

There’s one obvious downside — it raises the bar for outside contributions — but given the expertise necessary to contribute usefully to a static analysis tool in the first place, and to contribute to TypeScript in particular, I’m not sure it’s a big additional impediment.

josteink• 3 years ago

A benefit of the typescript compiler being written in typescript is that the compiler-makers get to dogfood their own language.

Rewriting it in rust would remove that important aspect c

AntonCTO2• 3 years ago

Rust alone wouldn't help. TypeScript is very hard to compile and to understand because of its complexity. I think there is a need for a different architectural approach with huge parallelization. Some (CI) servers have plenty of cores. Heck, my laptop has 20 threads.

muglug4• 3 years ago

Yeah, that helps them stay close to the community and prevents any air of superiority that can come from writing Rust.

But, while I’m sure it was really important initially, there are now very many test cases and early-adopters to help prevent regressions.

And they still have that large TypeScript codebase to test their new tool on — it wouldn’t vanish.

wffurr4• 3 years ago

Doesn’t seem worth the lost performance for the millions of Typescript users.

latchkey• 3 years ago

I know, because I rewrote a different 100KLOC typechecker myself in Rust (making a few small adjustments for a slightly different target language). It took me about a year.

It sounds like you could easily have a nice consulting gig for Microsoft.

comex• 3 years ago

Note that there’s at least one TypeScript type checker being developed in Rust by a third party:

https://github.com/dudykr/stc

DanHulton• 3 years ago

This is... good news, but I still cannot fathom using the default Typescript compiler for regular development. Seriously, leave the type-checking to your IDE and CICD chain, and switch to using tsx (https://www.npmjs.com/package/tsx) or swc (https://swc.rs/) and you will _immediately_ notice the difference in speed and productivity.

herpdyderp• 3 years ago

I wish there was also a much faster type checker!

vlovich1232• 3 years ago

I have absolutely 0 problems with the type checking that VSCode does. Always feel snappy. By comparison, command line performance is absolute crap though. The missing piece I suspect is a background daemon that auto-analyzes as you type like they do when you’re editing in VSCode to hide that latency. That’s a pretty standard technique to solve this problem (typically LSC although I don’t know how VSCode does TypeScript)

joshribakoff• 3 years ago

Doesn’t the comment you just replied to link to one? (Tsx)

jeroenhd2• 3 years ago

Leaving type checking to the IDE can cause a lot of unforseen problems. IDE support is imperfect, especially if you have some legacy JS code you need to integrate with, and sometimes it's even unreliable.

The Typescript transpiler does definitely slow things down but I've tried the "only check types during build" approach and while it starts out very nice and quickly, you end up wasting all that time you would've waited on tsc by chasing down impossible to find typing bugs and doing the necessary code restructuring to fix the problems your IDE missed. Only finding out about these bugs when pushing code (or even worse, when opening a pull/merge request) can be a lot more annoying than giving tsc half a second to catch up.

I do wish that tsc was faster, but on the other hand I can't say it's been that much of a problem for me.

Perhaps this is because I'm almost exclusively on Linux. tsc operates on tons of tiny files and Windows is notoriously slow at dealing with that, even with AV exclusions.

DangitBobby• 3 years ago

YMMV. I very rarely have the IDE and tsc disagree. Even though it happens occasionally, I'd much rather have instant type feedback as I work and have to fix some errant types with 10s+ feedback right before checking in than have 10s+ feedback all the time.

zastrowm• 3 years ago

I find the best middle ground is setting up the IDE to have TSC watch running while making changes, but using other tools for doing the actual compiling (vite for example). This allows me to refactor quickly - choosing when to ignore type errors - but also be notified of all the other call sites that I need to update, including in all of the files not currently open in the editor.

rektide• 3 years ago

I just have such a hard time imagining how the other type checkers keep parity.

TypeScript doesn't evolve super fast, but there are a steady stream of great improvements. I'd be so afraid I have either less type checking, things that silently pass/aren't checked, or intelligence that TypeScript has that other checkers don't have.

Also, as others say, just using --watch largely eliminates the problems of using tsc. I haven't worked on any truly huge codebases but it's been quite snappy. It's a longshot, but I wish TypeScript would also be it's own LSP too.

I definitely did love love love how blazingly fast & super easy to work with, no setup, Deno was. Incredibly refreshing, no ceremony.

brundolf2• 3 years ago

They don't keep parity. As far as I know, the official TypeScript implementation is the only major one that performs checking. There are tons of other options for stripping types that are much faster, but that's a much easier task

Deno uses tsc internally, and VSCode at least uses the official typescript language server, which I believe uses tsc internally

roqi• 3 years ago

Is there any effort to get browsers to support typescript? Transpiling is great, but all the tooling required by a typescript project, from transpiling to barreling, is becoming daunting.

mcluck2• 3 years ago

You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed

[1] https://github.com/tc39/proposal-type-annotations

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

jeroenhd2• 3 years ago

I like the idea of JS modules but they don't entirely negate the need for bundling. Sending a single compressed, tree shaken, minified JS file down the pipe can be a lot more efficient than waiting for the browser to load all those files.

Theoretically HTTP/2 push could've helped here, forcing the necessary files into the browser cache, but that's been removed from browsers.

wffurr4• 3 years ago

No, but the TypeScript compiler will also check types specified in JSDoc: https://devclass.com/2023/05/11/typescript-is-not-worth-it-f...

https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

nosianu3• 3 years ago

Is there any effort to get browsers to support typescript

You may want to read

https://news.ycombinator.com/item?id=35187377

https://news.ycombinator.com/item?id=35653653

Transpiling is entirely optional. Choose "esnext" as target and don't use the old and no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations.

If you write Typescript you already write pure Javascript, you just add type annotations, which are not part of the code and don't make it into the code.

Typescript mixes type checking and transpiler (Babel) and a few other thing in one big "blob" of a tool - unfortunately, the Unix way would have been to have separate tools. Which you can do and many do: Don't use "tsc" to create your .js code, only use it (through the IDE or standalone) to check types, and let Babel do any transpilations. It's much more flexible than "tsc" too.

What you are really asking is "Is there an effort to add types to ECMAscript" - and that does not look likely, because a) the existing solution already works well enough, and b) if you look at all the troubles and limitations you get when you use types you realize adding types is nearly impossible if you want to remain backwards compatible. If you use typed code, e.g. by using Typescript or Flow, you either end up with a lot of "any" types, or you have to code for the type checker. You cannot add reliable types to any previously pure Javascript code base. The code itself would have to change. Also, enough people don't want any types with their JS.

duped3• 3 years ago

no longer needed "namespace" (now: just use modules) and "enum" (now: just use an object literal annotated with "as const") - and all that is done is removal of the type annotations.

Both these things are needed. The workarounds you listed are not equivalent and not drop in replacements.

sroussey• 3 years ago

On the server side, you can use bun instead of node.

Cthulhu_• 3 years ago

Deno is a nice project for running TS without a separate transpile process, but that's server-side only.

Browser-side, they tried to add support for a second language via Dart, but that didn't work out.

brundolf2• 3 years ago

Extremely cool. It's crazy to think that the team built such an advanced tool for themselves, which very few other JS codebases can even benefit from. But the results speak for themselves, it was clearly worthwhile

TypeScript team released an explorer for performance tuning

Related Stories