Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Fascinating, but since Node now natively strips the TypeScript type annotations I rarely run the TSC. I really only run it now when I make a major regressive change and need static output from the compiler to see things I have failed to update.
Even for front end code destined for the browser I rely on Node's type stripping.
- fair, but, at the same time.. you may not think too much about it, but your editor is running the TypeScript language server all day long. presumably, so does your CI. presumably, so does your AI agent before feeling good about what it just did.by MiTypeScript
- Well, vscodium users are left in the cold, because the official extension isn't and most likely won't be on open-vsx repository, and the unofficial fork¹ is still WIP.by wartywhoa23
- Joel On Software: Rewriting software is the single worst strategic mistake that any software company can make. [1]
Microsoft: Take that, Joel!
;)
---
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
by lelele - To be fair, this wasn't just rewriting the software, it was translating logic in JS largely one-to-one into Go.
- Performance improvements, yay !
It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.
by stymaar - Performance of tsc wasn't an issue for small projects, and for larger projects it could be fixed by using incremental build option, and/or TS project references. Most either didn't care enough about the perf or were too lazy to set it up. TS7's perf boost will give people less of a reason to use these options.
- I think Rust is noticeably slow for two reasons:
1. The default settings aren’t well optimized. So the pattern a lot of people fall into is: start a project and everything’s fast, then add more code and dependencies and everything gets super slow. Then you Google how to fix it, change some compile settings and restructure your project and it speeds up again. Rust requires knowledge and effort to keep compile times reasonable - it’s not set up that way by default.
2. Rust Analyzer / cargo check is inefficient and throws a lot of data away each time instead of caching it. So in a larger project you’re waiting on it to catch up. Waiting on Rust Analyzer to check my code is easily the largest amount of time wasted, more so than actually compiling it.
But it should be said that this is being worked on: https://rust-lang.github.io/rust-project-goals/2025h2/relink...
by dabinat - As a TS dev, it’s probably because we already have such a high pain tolerance and low expectations.by appplication
- I didn’t care. Because to me the performance was a cost I was more than willing to pay for giving me sanity in JS land. Knowing you were passing the right types, right number of arguments, etc. Just the quality of documentation you got from having types at all above the nothing we had before was huge.
I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
by MBCook - Major ts pain point is scoping tsconfig settings for lib and types configurable for subsets of a project.
My project is a webapp, but I have node types in my ide tooling because of vite.config.ts, and playwright and unit tests. If I add a node api to a react component, tsc won't complain.
Current method to isolate dom lib from node lib requires project reference spaghetti, numerous tsconfig.json and tsbuildinfo output files, and avoiding emitting types with project references is cumbersome.
- Agree it is a pain. I have been using nx and it handles all that for you, playwright is a separate project with it's own twconfig and they all inherit from a root tsconfig.
I prefer nx for single applications and move shared code to "libraries" (I use non-buildable libs). It's pretty sweet for larger projects.
by paustint - Yes, tsconfig is a mess to scope. It needs a re-design to allow glob-based matching for all options and in typescript instead of jsonc.by silverwind
- No TypeScript compiler API yet, but I'm encouraged to hear that they're working on it.by skybrian
- It's coming in 7.1by simlevesque
- Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?by Exoristos
- Because it’s easier to work with one main language if you can get away with it.by Scarbutt
- I like TypeScript. It catches bugs in programs that Go doesn’t.by madeofpalk
- This is build-time performance, not run-time.by recursive
- For one, you’re not using TypeScript server-side. Whatever execution engine you are using is executing transpiled or JavaScript.
And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.
by semiquaver - Whether the performance difference between Go and JS (via node or whatever) matters depends on your use case - it definitely matters for the TS compiler, but it might not matter at all for your CRUD app.by thunderfork
- Because you can share types and even modules with your frontend project? Because for applications that aren't CPU-intensive it makes almost no difference? Because you are familiar with it and like it? Because of the humongous amount of libraries?by throw310822
- I'm glad the JSDoc type syntax is still getting some focus. It's my favorite way to use typescript in my own projects. Some of the syntax changes will be annoying to update but most of them seem to be for the better.by chroma_zone
- I'm glad that TypeScript uses JSDoc and not the hideous XML format [1] that Microsoft's other languages use.
[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
by raddan - After a few years of using Typescript, having to use type annotations and import basic language features like `abc` in Python feels like an absolute slog.by miiiiiike
- the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out).
huge congrats to the team!
looking forward to the Rust rewrite ;)
- They picked Go after meaningfully considering Rust (and others). I don't remember all the reasons for it but it was detailed in the original blog post.by paxys
- > most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out)
This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?
by tshaddox - Algorithm W is like undergrad level of sophistication. People who like HM more (and I am one) don't like it because it's "advanced" and to some extent exactly because it isn't. It's sound and fast and infers almost everything. TS seems to have one of those features now, so that's nice.by giraffe_lady
- > for the most advanced type system known to mankind
Honest question, what do you mean by this?
by mejutoco