Announcing TypeScript 6.0
67 points by ehamberg
67 points by ehamberg
…the team will be focused on bringing TypeScript 7.0 to stability. This is much closer than it might sound: we expect a release within a few months…
This is the biggest news in the release, and I’m glad is moving so quickly. TS7 will be a big win for those with large TypeScript codebases (myself included).
Do you have a rough idea of what the performance gains will be?
Significant. Completely unscientific benchmark on tsc --noEmit - ~48s currently, down to ~8s.
pnpm run cli tsc 48.80s user 10.11s system 135% cpu 43.460 total
pnpm exec tsgo --noEmit 8.47s user 5.19s system 716% cpu 1.907 total
The tsgo version is a little hampered as we still have some legacy tidy up to do and it's generating a raft of errors, where as vanilla passes.
about a bajillion times faster on the Notion codebase (ts monorepo w/ 5 million LoC)
@jitl if there is an equivalent in your codebase, are you able to replicate my tsc --noEmit case and give a quantum of the speedup? I did three runs and picked the fastest. Being golang I'm sure it's scaled-ish with the number of cores.
Virtually every runtime environment is now "evergreen". True legacy environments (ES5) are vanishingly rare.
Part of me feels that an ideology of roughly assuming an evergreen world will shift agency away from individuals and toward interested organizations, but perhaps that is conspiratorial-minded, or dismissive of the benefits, or just being outmoded/anti-modern/etc, or some combination thereof. So at risk of being out of my depth, I’ll muse that perhaps the endgame of the brutal treadmill is the pied piper tune of, “With AI, there are no treadmills, there are only artifacts.”
I think dropping target: es5 makes a lot of sense for TypeScript, especially given how the ecosystem has evolved. When TypeScript was young, ES6 was still a novelty, and it was common practice for quite a while to transpile down to ES5 both for both browsers and for Node.js. It was a nice QoL feature that you could use just tsc for everything, since otherwise you'd need to layer in Babel / Gulp / Webpack / whatever else to go from ES6 to ES5[^1].
Nowadays, if I saw a project using target: es5, I'd have... questions. I could only imagine using it if you're working with some pretty weird constraints: targeting niche runtimes like Duktape, targeting really old devices, etc. Not that those aren't cool! But it's very different from the original reason ES5 transpilation was introduced, so it seems fair to drop the baggage-- maybe even giving space for tools better fit-to-purpose to grow.
[^1]: (if I wanted to be cynical / conspiracy-minded: adding target: es5 in the first place was a form of lock-in! it shifted a lot of momentum away from Babel, pushing more and more stuff into the TypeScript ecosystem. but... I don't really feel that cynical about it, it was well-motivated at the time)
With AI, TypeScript needs more tokens than JS for the same output, while also increasing iteration time. Not sure how that will work for them in the long run.
This is only true initially. Once a project reaches a certain size, the agent will start wasting tokens re-discovering types which are explicit in TypeScript.
Maybe the output needs slightly more tokens, but the input or processing needs much less, since there is more information.
This has me wondering, once again, about extracting runtime type information (eg from CI runs via CDP) and saving it to .d.ts files.
I'm still looking forward to see how the programmatic API for v7 will turn out to be, and how it'll be possible to integrate it in js projects.
The monaco editor uses the TypeScript compiler under the hood (running in a web worker), and the editor is used in lots of other Microsoft products, so I'm hoping they'll make it as smooth as possible to migrate.
editor speed/integration was explicitly mentioned in an earlier blog post. tl;dr: faster; lsp-based. see https://devblogs.microsoft.com/typescript/typescript-native-port/
That’s a lot of deprecation and a lot of “use external tool/compiler/bundler to perform this instead”
I think it makes a lot of sense to shed as much cruft as you can when your next release will be a grounds-up rewrite.
TS had a lot of half-baked identities (consider how in the initial days it actively added new stuff to the language i.e. enums, or how acted as a kinda-sorta bundler by concatenating all .ts files into a single .js file), but the tooling around it has since matured and nowadays it simply doesn't really make sense for it to be anything more than a typechecker/compiler.