DanRosenwasser

Hey there, TypeScript team member here. The tsrs project has been extremely interesting to see come together. We've been working with the maintainers to better understand how tsrs is fast and what sorts of optimizations it uses are safe. We even did our own Rust vibe port and what we currently suspect is that a lot of the speed does not just come down to language choice, and some of what is going to make TS 7.1 faster and leaner (see the charts in the blog post) actually comes from optimizations discovered in tsrs.

We think the wasm and oxlint integration makes a lot of sense for Cloudflare's needs, so this investment makes sense. At the same time, we'll be working hard and collaborating to make the official TypeScript toolset faster and even more efficient.

Congrats to the tsrs team on making this official. We're excited and we look forward to continuing on collaboration!

TypeScript team member here - this is impressive work, and it's honestly crazy that 3 of these ports have popped up in the last week! I'm currently AFK but we're hoping to learn more and we'll have more to say on this soon.

Yes, but your TypeScript code has to be checked against the libraries in node_modules, and it is significantly costlier to check against implementation files (the .ts/.mts files) than the produced declaration files (the .d.ts files).

> How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase?

esbuild doesn't rely on TypeScript at all, so there's no issue there.

With tsdown on the other hand, it depends on if you use --isolatedDeclarations. If not, you can install TypeScript 6 side-by-side (instructions for this are on the blog)

The methodology used in this paper was extremely bad. There is no reason there should be any disparity between a TypeScript and JavaScript benchmark.

Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.

> It is possible to use the language server for syntax highlighting. I am not aware of any particularly strong reasons why one would want to (or not want to) do this. The language server can be a more complicated program and so could surface particularly detailed information about the syntax; it might also be slower than tree-sitter.

We (TypeScript) used to do this for Visual Studio prior to tmLanguage. It was nice because we didn't have to write a second parser. Our parser was already error-tolerant and incremental, and syntax highlighting just involved descending into the syntax tree's tokens. So there was no room for divergence bugs in parsers, and there was also no need to figure out how to encode oddities and ambiguity-breaking logic in limited formats like tmLanguage.

This all predated TSServer (which predated LSP, though that's coming in TypeScript 7). The latency for syntax highlighting over JSON was too much, and other editors often didn't make syntax highlighting available outside of tmLanguage anyway. Eventually semantic highlighting became a thing, which is more latency-tolerant, and overlays colors on top of a syntactic highlighter in VS Code.

The other issue with this approach was that we still needed a dedicated thread just for fast syntax highlighting. That thread was a separate instance of the JS language service without anything shared, so that was a decent amount of memory overhead just for syntax highlighting.