8 ms·

TypeScript 7

720 points by DanRosenwasser 3mo ago

dimitropoulos 3mo ago
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 ;)
- DonaldPShimoda 3mo ago
  Most complex, perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate? (I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
  - dimitropoulos 3mo ago
    good points, let's get negated types and higher kinded types in there then you've got yourself a deal. maybe regex thrown in too for flavor
- hoppp 3mo ago
  I am not sure a rust rewrite would be meaningful. Go is great because it's fast to code.It's easy to reimplement typescript in go 1:1 just by looking at the code. Rust on the other hand would take a lot longer to develop. Maybe rust is 20% faster than go but overall the increase from typescript with go is good enough. Maybe rust would yield a 14 times speedup over the 11 times in vscode but go is already good enough to make a huge difference.
  - dimitropoulos 3mo ago
    jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that. in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types. [1] https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
    - hoppp 3mo ago
      Yes, I saw the YouTube video about Jevons paradox from Hank Green yesterday. :)
      - hebrox 3mo ago
        *The
        faefox 3mo ago
        Fine, the Hank Green.
      - annjose 3mo ago
        The Jevon's Paradox. And it is not a paradox :-)
        regular_trash 3mo ago
        It actually is a paradox, a veridical paradox. But I'm splitting hairs lol
    - tancop 3mo ago
      the difference is with roads you dont get a lot of good secondary effects, one lane is just like the next. benefits are linear with the cost so they balance out. but with typescript and software in general they can be exponential. fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.
  - nicoburns 3mo ago
    The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance. It probably won't ever happen though. > It's easy to reimplement typescript in go 1:1 just by looking at the code. That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.
    - Cthulhu_ 3mo ago
      Can you elaborate why that's a factor? The tools are just binaries in how they're used, the language they're written in is no longer a factor then. It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.
      - nicoburns 3mo ago
        > The tools are just binaries in how they're used They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.
  - afdbcreid 3mo ago
    A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1. But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
- tshaddox 3mo ago
  > 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)?
  - whilenot-dev 3mo ago
    I don't think GP was referring to transpilation speed when they wrote "most advanced type system known to mankind".
    - tshaddox 3mo ago
      The original poster was referring to the golang port of TypeScript which was done almost exclusively for performance reasons. They weren’t just making an unprompted comparison of two type systems.
      - dimitropoulos 3mo ago
        I was referring to the type system in the formal "specification" sense, not the implementation details of the compiler, such as the compiler's runtime (Go, or, in the past, JavaScript/Node). it's too bad there's no specification for TypeScript the way there is for JavaScript and many other things (most?). in that sense, the performance of the type system is uncoupled from the semantics of the type system itself (as the Go port has thoroughly illustrated!). I mentioned Hindley-Milner because I am under the belief that the HM system (as in OCaml) is, in the same formal/semantic/specification sense, perhaps more advanced. but, as is often with these things, the rubber meets the road on which one of them has been shown to actually run Doom, lol, to which TypeScript is currently the undisputed king.
- samuell 3mo ago
  Steve Francia (author of Hugo and a bunch of other top Go projects) wrote up some thoughts of Go's fit in the agentic era: https://spf13.com/p/go-the-agentic-language/ https://spf13.com/p/go-the-agentic-language/
  - mightyham 3mo ago
    > in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
    - Cthulhu_ 3mo ago
      I'm reading a lot of style / flavor / quality / vibes in your reply, something that will be different between every developer (for the most part); the thing with Go is that there's a lot less of that in the wider ecosystem.
- paxys 3mo ago
  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.
  - Cthulhu_ 3mo ago
    There's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads: The blog post: https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-... Why Go? https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410 https://github.com/microsoft/typescript-go/discussions/410
- mejutoco 3mo ago
  > for the most advanced type system known to mankind Honest question, what do you mean by this?
  - culi 3mo ago
    It means they really like TypeScript and they hope to influence some juniors into investing themselves into it
  - dimitropoulos 3mo ago
    I answered here https://news.ycombinator.com/item?id=48838629 https://news.ycombinator.com/item?id=48838629
    - mejutoco 3mo ago
      Are you aware of languages like lean or idris? In that comment you mention doom in ts types.
      - dimitropoulos 3mo ago
        nope! never heard of them! (note: I'm the guy that did the Doom in TS types thing) what type-level fun do they bring to the table?
- giraffe_lady 3mo ago
  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.
MiTypeScript 3mo ago
sub-1day-first-frame-of-DOOM LFGGGGGG
- chamomeal 3mo ago
  I am also pretty stoked about the doom performance improvements lol
willchen 3mo ago
really excited to see this release! i've been using TypeScript for several projects like https://github.com/dyad-sh/dyad https://github.com/dyad-sh/dyad which is >250k lines of TypeScript and the speed-up makes things like running typescript check as a pre-commit hook painless thanks DanRosenwasser and team for building such an awesome tool for so many years!
terpimost 3mo ago
Are there any plans about wasm version?
- spankalee 3mo ago
  Yes, but no official builds yet that I know. This is a really important issue for online playgrounds and IDEs.
  - raddan 3mo ago
    I am a little surprised that they rewrote the compiler in Go instead of just compiling the existing compiler to WASM. The linked announcement does not talk about a WASM alternative at all (rewriting a compiler is a risky move!). Does anybody know what the rationale was to do a full rewrite? The article really emphasizes speed, but not much else. Was it Go's concurrency affordances that made the switch worthwhile?
    - jakebailey 3mo ago
      The compiler was written in TS; it wouldn't make much sense to compile TS to Wasm, only to have that same code run in the same interpreter as the JS code. And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
  - jakebailey 3mo ago
    Hoping to start getting Wasm builds out soon; it's a little unclear what people want when they say "Wasm", because it could mean - LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build which muddies the water a bit, but I'm sure we can get it working
    - notnullorvoid 3mo ago
      I think all 3 are pretty important for using TS in online sandboxes and IDEs.
deleted 3mo ago
[deleted]
adamddev1 3mo ago
Remember when people would argue about how types weren't worth the effort? I love TypeScript, if nothing else for how it's been able to popularize types.
- ajkjk 3mo ago
  I don't think ... serious people... argued that. That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.
  - samtheprogram 3mo ago
    ....they did ...and... the camp still exists
    - ajkjk 3mo ago
      well, as I said, I don't take them seriously :p
  - ChadNauseam 3mo ago
    It's easy to say that now, but it used to be that all mainstream typed languages had absolutely terrible type systems that got in your way as much as they helped
    - steve_adams_86 3mo ago
      Absolutely, TypeScript is remarkably expressive in my opinion. The inference and option to bail out with `any` is nice for some teams in some cases, too. They did an excellent job of making it accessible.
deleted 3mo ago
[deleted]
chroma_zone 3mo ago
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.
- raddan 3mo ago
  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-reference/xmldoc/recommended-tags https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
  - seabrookmx 3mo ago
    I'm a big C# fan but XML docstrings definitely suck. We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.
    - adzm 3mo ago
      This is my biggest annoyance with c#. I've always wanted to try to add jsdoc or something in the compiler. Little more annoying than having to use > and < in a comment
blurb2023 3mo ago
finally it uses a normal language backend =)
stymaar 3mo ago
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.
- appplication 3mo ago
  As a TS dev, it’s probably because we already have such a high pain tolerance and low expectations.
- MBCook 3mo ago
  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.
  - stymaar 3mo ago
    > But I never thought about giving it up due to compiler performance. Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds. Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…
- notnullorvoid 3mo ago
  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.
- dabinat 3mo ago
  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-dont-rebuild.html https://rust-lang.github.io/rust-project-goals/2025h2/relink...
NetOpWibby 3mo ago
The speed-up improvements are incredible, can't wait for this to rollout to Deno. Everything I build uses TypeScript so I'm excited to see just how quick my apps compile.
- MoonWalk 3mo ago
  I was wondering how this kind of change makes its way into environments like Deno. I'm building a project on Deno too. As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?
  - skybrian 3mo ago
    Deno resolves import statements in its own way. For example, you can import URLs and JSR packages directly, but the file is usually loaded from Deno’s global module cache. To resolve imports you need to look at the deno.json file and deno.lock file. They also added Deno Workspaces (monorepos) which adds more complexity. This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it. I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
    - ameliaquining 3mo ago
      They actually have partial unstable TypeScript 7 support already. Internal documentation of how it works: https://github.com/denoland/deno/blob/main/cli/tsc/README.md#typescript-go-integration https://github.com/denoland/deno/blob/main/cli/tsc/README.md...
    - VerifiedReports 3mo ago
      Thanks for the reply. I don't understand what a TypeScript version bump has to do with import statements, though.
skybrian 3mo ago
No TypeScript compiler API yet, but I'm encouraged to hear that they're working on it.
- simlevesque 3mo ago
  It's coming in 7.1
miiiiiike 3mo ago
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.
Exoristos 3mo ago
Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?
- semiquaver 3mo ago
  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.
  - IshKebab 3mo ago
    > 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. I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.
  - dbbk 3mo ago
    "In their right mind?" I wouldn't start a project in anything other than TypeScript now. My platform is a monorepo across web and native mobile (Expo), and is TypeScript throughout. All my types flow everywhere automatically. Even the shape of a database table is shared with the native app with tRPC. Nothing can break the type contract anywhere. How would you do that with another language?
    - simg 3mo ago
      >How would you do that with another language? WASM All my side projects for the last year+ have used full stack Rust.
  - atraac 3mo ago
    Absolutely everyone who doesn't work with hardware, or on specific problems, because it's far more popular, easy to hire for, easy to deliver an MVP with and easy to have people jump between frontend and backend with. I'm saying this as someone who specialized in .NET before and now writes Node/TS. I simply grew out of the opinion that language/architecture is everything. When you make a product delivering quicker matters more than choosing a marginally more performant language, unless you're solving a very specific problem that requires that performance. Adding one more server costs less than hiring engineer for a more niche language and if you have the success that requires you to scale up that much, money is probably not the problem anymore. Granted we're in LLM era where everyone can write anything but it's still better to have people vibe in language they actually know, so they understand what's happening. You can always extract services later on and rewrite them in a more performant way, noone's stopping you.
shimman 3mo ago
[dead]
austinthetaco 3mo ago
I'm still not sold on typescript. I've used it off and on professionally for years and it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you technically can do functional programming (but as i said its a pain) and YES its optional and you dont have to use it everywhere, but try pulling that maneuver on a technical team "lets use typescript where we each feel like it". I am still of the opinion that well organized and named JS is all that anyone needs and typescript only exists for fresh graduates and fleeing OOP devs. edit: also the downvote button HN is not for disagreeing with comments or unpopular opinions.
- jakubmazanec 3mo ago
  > I am still of the opinion that well organized and named JS is all that anyone needs You probably didn't work on any medium or large codebase and didn't have to do a refactor. > it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
  - austinthetaco 3mo ago
    You really should just not assume things about people with no reason other than "they dont like the things i like so therefor they must not be experienced". I've worked on plenty of very very large codebases with large teams. > What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created. did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and hinting support. The typescript creation team was literally led by the guy who made C#.
    - jakubmazanec 3mo ago
      > You really should just not assume things about people with no reason other than "they dont like the things i like That's not the reason for my comment. I truly don't understand how after so many years someone "isn't sold" on TypeScript. Sure, you don't have to use it if you don't want to, but if don't see how it's truly essential in current JS development, I don't know what else to assume, other than OP doesn't have enough experience. > it was created by microsoft It was created at Microsft, but it was crated by Anders Hejlsberg who, I'm pretty sure, didn't want to just "create a safehaven to C# and java devs", he was actually solving real problems with JS development, completely orthogonal. You can argue that TS's first syntax was very C/C# inspired, and that Anders also created C#, but that's not what OP meant (or at least how it read).
perrohunter 3mo ago
For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?
- lelandfe 3mo ago
  If you’re continuing to use the previous version in CI, there’s no reason to not use this locally. It’s a tremendous speed upgrade.
  - herpdyderp 3mo ago
    The reason to not use it locally is false negatives or false positives compared to your CI version. Your local tsc will not match the results of your CI tsc.
- sheept 3mo ago
  It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.
- herpdyderp 3mo ago
  Depends on your tooling. I can't update yet due to ESLint package dependency mismatches. I'll have to wait for all the ESLint plugins to update. There may also be new failures in your code from the v6 to v7 update. I had only a very minor one though in my initial test.
  - dmix 3mo ago
    Eslint is like an anchor on upgrading anything (including Eslint itself). I'll be happy to move on from it.
    - Timon3 3mo ago
      I've been really, really happy with oxlint. It has all the rules I usually need and the configs etc. tend to just work, whereas I don't know how much time I spent getting ESLint to work in slightly more complex repo setups.
fishgoesblub 3mo ago
Are these performance improvements just for transpiling the Typescript to JS, or actually running programs written in Typescript?
- tpetry 3mo ago
  These are for type-checking. Transpiling takes barely any time.
- culi 3mo ago
  TypeScript isn't a runtime language
m3h 3mo ago
The speed up numbers based on their testing: Codebase | TypeScript 6 | TypeScript 7 | Speedup ------------|--------------|--------------|-------- vscode | 125.7s | 10.6s | 11.9x sentry | 139.8s | 15.7s | 8.9x bluesky | 24.3s | 2.8s | 8.7x playwright | 12.8s | 1.47s | 8.7x tldraw | 11.2s | 1.46s | 7.7x Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun). Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?
- hackerbrother 3mo ago
  Do you think Bun's migration was irresponsible?
  - ricardobeat 3mo ago
    Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear. Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
    - docmars 3mo ago
      Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
      - 3mo ago
deleted 3mo ago
[deleted]
devtoolsuite 3mo ago
[flagged]
_pdp_ 3mo ago
I've been waiting for this for a long long time. Congrats on the release.
pmkary 3mo ago
Glorious Day!
m_ke 3mo ago
After running out of Fable credits in a day on my max plan I started looking around for ways to trim down my token usage and came to the realization that all of the type spaghetti that opus wrote is probably eating up like 50-70% of my tokens. A clean django project is probably 3-4x less code than the equivalent TS based service. It made me consider dropping strict mode and defaulting to js for most simple things.
- jw1224 3mo ago
  Interesting, I've come to the opposite conclusion: a lack of types (or types that are only weakly enforced) costs me significantly more tokens in the long-run to maintain, and makes it far too easy for models to silently introduce bugs. I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers. (This would drive me absolutely insane, but my agents get over it pretty quickly!)
- IceDane 3mo ago
  Why not just do like.. actual engineering, and stay in control of what the LLM builds?
- kodama-lens 3mo ago
  In a world where code generation is cheap, why use untyped languages? Types add confidence, stricter interfaces, and most likely a better runtime performance.
  - m_ke 3mo ago
    With agentic coding the costs of tokens compound with each message / tool call and etc. Having to load in and update large files makes things slower and way more expensive. Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase https://www.databricks.com/blog/benchmarking-coding-agents-d... simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs. PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).
herpdyderp 3mo ago
I'm only seeing a speedup of 4x compared to v6, but I'll take it!
- brikym 3mo ago
  3 - 3.5x here. I'm very happy with that though.
ksec 3mo ago
I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?
- kristianp 3mo ago
  Just about every release of go has incremental performance improvements [1]. It's a very stable language, so don't expect anything mind-blowing. For example the latest 1.26 moved a new garbage collector from experimental to production [2]. In the latest compiler they state that: "The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance". [1] https://go.dev/doc/devel/release https://go.dev/doc/devel/release [2] https://go.dev/doc/go1.26 https://go.dev/doc/go1.26
  - ksec 3mo ago
    Thanks I have somehow missed this. My mental model is that Go is still 1.5 to 2.5x speed of C hence I asked the question. This is likely wrong number now given so much has been happening without much fanfare. ( or may be I just missed all of it ) Thanks for the link.
dzonga 3mo ago
congrats to the typescript team. I have a longer blog post or audio to post. but in short - the javascript/typescript ecosystem is like working with wood. you can have your cheap, laminate cardboard wood - Ikea type - the code equivalent will be vibe coded apps that are not original. then on the high end - you can have your crafted furniture | wooden skyscrapers - that use custom joinery & lamination techniques using young lumber to make to make beams that are fireproof. you can also have high end stuff in the javascript/typescript ecosystem that uses A.I as one uses powerful machine tools but with crafting in mind. for those that dare to make or dare to do - embrace the typescript|javascript ecosystem.
some-guy 3mo ago
I remember going from Java in IntelliJ straight to TypeScript at work for another project, and I recall how _slow_ everything was in the editor(s). I have been using TypeScript 7 RC and most of my complaints have gone away with regards to speed.
mckee_plus_plus 3mo ago
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.
- paustint 3mo ago
  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.
- silverwind 3mo ago
  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.
settled 3mo ago
Great links but unfortunately it doesn't work with ts-jest out of the box, had to do the side-by-side compatibility workaround. Major releases should give more confidence for common tools like testing instead of pointing backwards
- Timon3 3mo ago
  I don't think it's reasonable to expect the TS team to hold back the release until the ecosystem has caught up.
  - settled 3mo ago
    [dead]
austin-cheney 3mo ago
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.
- MiTypeScript 3mo ago
  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.
gokulrajaram 3mo ago
[flagged]
linzhangrun 3mo ago
Congratulations! Although I'd prefer the C# authors to rewrite it in C# AOT :)
- anankaie 3mo ago
  Or implement tsaot
  - knocte 3mo ago
    Yeah! This way TS at runtime would also benefit from the speedup, not just the compilation.
jeswin 3mo ago
Congrats on launch. The code is beautiful, and the test suite is quite solid. Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts https://github.com/tsoniclang/tsts It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.
- lioeters 3mo ago
  That tsts project looks very interesting. I suppose there are various practical reasons for doing this. For me I'm just glad to see an easy way to run the newest TypeScript compiler (and I guess type checker?) in the browser. There's an unofficial Wasm build of tsgo/ts7, if I recall was about 12Mb. Another advantage of tsts I imagine is the ease of diving into the compiler internals as it's running (interpreted) instead of a binary distribution, another language (though I like Go), or having to recompile it on every change. Good luck with the project, I'll be keeping an eye on its progress with interest.
  - jeswin 3mo ago
    Thanks. The idea is that many projects (including tsts itself) can be run unmodified on a JS runtime, or as a native binary via NativeAOT/C# or Rust.
shafiq235 3mo ago
Its the best thing ever. I have been waiting months for this Thanks to Microsoft for the first - NON SLOP release
zigae 3mo ago
[flagged]
ShinyLeftPad 3mo ago
Does lack of compiler API mean typescript-language-server is not going to play nice with 7.0?
- kristianp 3mo ago
  https://news.ycombinator.com/item?id=48840113 https://news.ycombinator.com/item?id=48840113 seems to answer that question. I.e. an api for the compiler is being worked on.
  - ShinyLeftPad 3mo ago
    Sure but typescript-language-server is different because it's also from MS.
- sharlos201068 3mo ago
  I remember reading they're rebuilding it to use the same LSP as other languages instead of its custom thing.
  - ShinyLeftPad 3mo ago
    it's not? pretty sure I use typescript-language-server as generic LSP from my editor for years
amai 3mo ago
So the compiler written in Go is nearly 10x faster than the old one written in JavaScript
jekuer 3mo ago
TS gained so much more relevance with AI. Hope they do not mess it up!
ramon156 3mo ago
Awesome! Off-topic, can we get something like TS for PHP now? Tools like PHPStan work fine, but I'd love a typed language on top of PHP that can catch a lot of things on compile time. I want to be able to compile my symfony routes, avoiding as much as possible on runtime. I've been thinking about this since 2022 and haven't really gotten further than "Hmm, I would like this". I'm aware that tooling catches most stuff, but being able to shift this even more to the left (compile time) would be great. I'm just very used to Rust, where my hand is being held
- Cthulhu_ 3mo ago
  Have you considered Hack (https://hacklang.org/ https://hacklang.org/)? it's PHP with types from Facebook, probably the biggest contributor to the PHP ecosystem at the moment. It does need a compiler though, unlike TS where an interpreter can just strip / ignore type annotations. But IMO, a compile step is worth it if you get type assurances in return.
joygqz 3mo ago
[dead]
plasticeagle 3mo ago
I love Typescript, I think it's a fascinating language with a great runtime. It's already very fast to execute, but the compile times have been awful. Especially when you start to run production builds with minification and whatnot. So I'm interested on what exactly has been sped up here. I can see compile times have been, but is that it? I suppose the runtime itself was always native code, and already very fast.
- inbx0 3mo ago
  What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.
- skybrian 3mo ago
  The TypeScript compiler is (was) slow, but you don’t need it to minify code. This sounds like some other problem with the tools in your project’s build. (There are faster tools available these days.) A faster type checker will help with performance problems in text editors since type info is needed for a lot of queries.
wartywhoa23 3mo ago
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. ¹https://github.com/Nsttt/typescript-go https://github.com/Nsttt/typescript-go
lelele 3mo ago
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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- sharlos201068 3mo ago
  To be fair, this wasn't just rewriting the software, it was translating logic in JS largely one-to-one into Go.
aabbcc1241 3mo ago
I've not figure out how to run typescript script directly with type-checking (in dev mode) with typescript 7. ts-node cannot be used with typescript@7. although node@24 can directly run typescript file, but stripe the types, without type-checking, also it require changing the import path with .ts, and it doesn't support import .tsx files.

720 points by DanRosenwasser 3mo ago

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 ;)

DonaldPShimoda 3mo ago
Most complex, perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate? (I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
- dimitropoulos 3mo ago
  good points, let's get negated types and higher kinded types in there then you've got yourself a deal. maybe regex thrown in too for flavor
hoppp 3mo ago
I am not sure a rust rewrite would be meaningful. Go is great because it's fast to code.It's easy to reimplement typescript in go 1:1 just by looking at the code. Rust on the other hand would take a lot longer to develop. Maybe rust is 20% faster than go but overall the increase from typescript with go is good enough. Maybe rust would yield a 14 times speedup over the 11 times in vscode but go is already good enough to make a huge difference.
- dimitropoulos 3mo ago
  jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that. in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types. [1] https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
  - hoppp 3mo ago
    Yes, I saw the YouTube video about Jevons paradox from Hank Green yesterday. :)
    - hebrox 3mo ago
      *The
      - faefox 3mo ago
        Fine, the Hank Green.
    - annjose 3mo ago
      The Jevon's Paradox. And it is not a paradox :-)
      - regular_trash 3mo ago
        It actually is a paradox, a veridical paradox. But I'm splitting hairs lol
  - tancop 3mo ago
    the difference is with roads you dont get a lot of good secondary effects, one lane is just like the next. benefits are linear with the cost so they balance out. but with typescript and software in general they can be exponential. fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.
- nicoburns 3mo ago
  The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance. It probably won't ever happen though. > It's easy to reimplement typescript in go 1:1 just by looking at the code. That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.
  - Cthulhu_ 3mo ago
    Can you elaborate why that's a factor? The tools are just binaries in how they're used, the language they're written in is no longer a factor then. It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.
    - nicoburns 3mo ago
      > The tools are just binaries in how they're used They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.
- afdbcreid 3mo ago
  A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1. But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
tshaddox 3mo ago
> 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)?
- whilenot-dev 3mo ago
  I don't think GP was referring to transpilation speed when they wrote "most advanced type system known to mankind".
  - tshaddox 3mo ago
    The original poster was referring to the golang port of TypeScript which was done almost exclusively for performance reasons. They weren’t just making an unprompted comparison of two type systems.
    - dimitropoulos 3mo ago
      I was referring to the type system in the formal "specification" sense, not the implementation details of the compiler, such as the compiler's runtime (Go, or, in the past, JavaScript/Node). it's too bad there's no specification for TypeScript the way there is for JavaScript and many other things (most?). in that sense, the performance of the type system is uncoupled from the semantics of the type system itself (as the Go port has thoroughly illustrated!). I mentioned Hindley-Milner because I am under the belief that the HM system (as in OCaml) is, in the same formal/semantic/specification sense, perhaps more advanced. but, as is often with these things, the rubber meets the road on which one of them has been shown to actually run Doom, lol, to which TypeScript is currently the undisputed king.
samuell 3mo ago
Steve Francia (author of Hugo and a bunch of other top Go projects) wrote up some thoughts of Go's fit in the agentic era: https://spf13.com/p/go-the-agentic-language/ https://spf13.com/p/go-the-agentic-language/
- mightyham 3mo ago
  > in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
  - Cthulhu_ 3mo ago
    I'm reading a lot of style / flavor / quality / vibes in your reply, something that will be different between every developer (for the most part); the thing with Go is that there's a lot less of that in the wider ecosystem.
paxys 3mo ago
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.
- Cthulhu_ 3mo ago
  There's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads: The blog post: https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-... Why Go? https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410 https://github.com/microsoft/typescript-go/discussions/410
mejutoco 3mo ago
> for the most advanced type system known to mankind Honest question, what do you mean by this?
- culi 3mo ago
  It means they really like TypeScript and they hope to influence some juniors into investing themselves into it
- dimitropoulos 3mo ago
  I answered here https://news.ycombinator.com/item?id=48838629 https://news.ycombinator.com/item?id=48838629
  - mejutoco 3mo ago
    Are you aware of languages like lean or idris? In that comment you mention doom in ts types.
    - dimitropoulos 3mo ago
      nope! never heard of them! (note: I'm the guy that did the Doom in TS types thing) what type-level fun do they bring to the table?
giraffe_lady 3mo ago
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.

MiTypeScript 3mo ago

sub-1day-first-frame-of-DOOM LFGGGGGG

chamomeal 3mo ago
I am also pretty stoked about the doom performance improvements lol

willchen 3mo ago

really excited to see this release! i've been using TypeScript for several projects like https://github.com/dyad-sh/dyad https://github.com/dyad-sh/dyad which is >250k lines of TypeScript and the speed-up makes things like running typescript check as a pre-commit hook painless thanks DanRosenwasser and team for building such an awesome tool for so many years!

terpimost 3mo ago

Are there any plans about wasm version?

spankalee 3mo ago
Yes, but no official builds yet that I know. This is a really important issue for online playgrounds and IDEs.
- raddan 3mo ago
  I am a little surprised that they rewrote the compiler in Go instead of just compiling the existing compiler to WASM. The linked announcement does not talk about a WASM alternative at all (rewriting a compiler is a risky move!). Does anybody know what the rationale was to do a full rewrite? The article really emphasizes speed, but not much else. Was it Go's concurrency affordances that made the switch worthwhile?
  - jakebailey 3mo ago
    The compiler was written in TS; it wouldn't make much sense to compile TS to Wasm, only to have that same code run in the same interpreter as the JS code. And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...
- jakebailey 3mo ago
  Hoping to start getting Wasm builds out soon; it's a little unclear what people want when they say "Wasm", because it could mean - LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build which muddies the water a bit, but I'm sure we can get it working
  - notnullorvoid 3mo ago
    I think all 3 are pretty important for using TS in online sandboxes and IDEs.

deleted 3mo ago

[deleted]

adamddev1 3mo ago

Remember when people would argue about how types weren't worth the effort? I love TypeScript, if nothing else for how it's been able to popularize types.

ajkjk 3mo ago
I don't think ... serious people... argued that. That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.
- samtheprogram 3mo ago
  ....they did ...and... the camp still exists
  - ajkjk 3mo ago
    well, as I said, I don't take them seriously :p
- ChadNauseam 3mo ago
  It's easy to say that now, but it used to be that all mainstream typed languages had absolutely terrible type systems that got in your way as much as they helped
  - steve_adams_86 3mo ago
    Absolutely, TypeScript is remarkably expressive in my opinion. The inference and option to bail out with `any` is nice for some teams in some cases, too. They did an excellent job of making it accessible.

deleted 3mo ago

[deleted]

chroma_zone 3mo ago

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.

raddan 3mo ago
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-reference/xmldoc/recommended-tags https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
- seabrookmx 3mo ago
  I'm a big C# fan but XML docstrings definitely suck. We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.
  - adzm 3mo ago
    This is my biggest annoyance with c#. I've always wanted to try to add jsdoc or something in the compiler. Little more annoying than having to use > and < in a comment

blurb2023 3mo ago

finally it uses a normal language backend =)

stymaar 3mo ago

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.

appplication 3mo ago
As a TS dev, it’s probably because we already have such a high pain tolerance and low expectations.
MBCook 3mo ago
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.
- stymaar 3mo ago
  > But I never thought about giving it up due to compiler performance. Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds. Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…
notnullorvoid 3mo ago
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.
dabinat 3mo ago
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-dont-rebuild.html https://rust-lang.github.io/rust-project-goals/2025h2/relink...

NetOpWibby 3mo ago

The speed-up improvements are incredible, can't wait for this to rollout to Deno. Everything I build uses TypeScript so I'm excited to see just how quick my apps compile.

MoonWalk 3mo ago
I was wondering how this kind of change makes its way into environments like Deno. I'm building a project on Deno too. As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?
- skybrian 3mo ago
  Deno resolves import statements in its own way. For example, you can import URLs and JSR packages directly, but the file is usually loaded from Deno’s global module cache. To resolve imports you need to look at the deno.json file and deno.lock file. They also added Deno Workspaces (monorepos) which adds more complexity. This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it. I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
  - ameliaquining 3mo ago
    They actually have partial unstable TypeScript 7 support already. Internal documentation of how it works: https://github.com/denoland/deno/blob/main/cli/tsc/README.md#typescript-go-integration https://github.com/denoland/deno/blob/main/cli/tsc/README.md...
  - VerifiedReports 3mo ago
    Thanks for the reply. I don't understand what a TypeScript version bump has to do with import statements, though.

skybrian 3mo ago

No TypeScript compiler API yet, but I'm encouraged to hear that they're working on it.

simlevesque 3mo ago
It's coming in 7.1

miiiiiike 3mo ago

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.

Exoristos 3mo ago

Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?

semiquaver 3mo ago
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.
- IshKebab 3mo ago
  > 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. I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.
- dbbk 3mo ago
  "In their right mind?" I wouldn't start a project in anything other than TypeScript now. My platform is a monorepo across web and native mobile (Expo), and is TypeScript throughout. All my types flow everywhere automatically. Even the shape of a database table is shared with the native app with tRPC. Nothing can break the type contract anywhere. How would you do that with another language?
  - simg 3mo ago
    >How would you do that with another language? WASM All my side projects for the last year+ have used full stack Rust.
- atraac 3mo ago
  Absolutely everyone who doesn't work with hardware, or on specific problems, because it's far more popular, easy to hire for, easy to deliver an MVP with and easy to have people jump between frontend and backend with. I'm saying this as someone who specialized in .NET before and now writes Node/TS. I simply grew out of the opinion that language/architecture is everything. When you make a product delivering quicker matters more than choosing a marginally more performant language, unless you're solving a very specific problem that requires that performance. Adding one more server costs less than hiring engineer for a more niche language and if you have the success that requires you to scale up that much, money is probably not the problem anymore. Granted we're in LLM era where everyone can write anything but it's still better to have people vibe in language they actually know, so they understand what's happening. You can always extract services later on and rewrite them in a more performant way, noone's stopping you.

shimman 3mo ago

[dead]

austinthetaco 3mo ago

I'm still not sold on typescript. I've used it off and on professionally for years and it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you technically can do functional programming (but as i said its a pain) and YES its optional and you dont have to use it everywhere, but try pulling that maneuver on a technical team "lets use typescript where we each feel like it". I am still of the opinion that well organized and named JS is all that anyone needs and typescript only exists for fresh graduates and fleeing OOP devs. edit: also the downvote button HN is not for disagreeing with comments or unpopular opinions.

jakubmazanec 3mo ago
> I am still of the opinion that well organized and named JS is all that anyone needs You probably didn't work on any medium or large codebase and didn't have to do a refactor. > it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
- austinthetaco 3mo ago
  You really should just not assume things about people with no reason other than "they dont like the things i like so therefor they must not be experienced". I've worked on plenty of very very large codebases with large teams. > What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created. did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and hinting support. The typescript creation team was literally led by the guy who made C#.
  - jakubmazanec 3mo ago
    > You really should just not assume things about people with no reason other than "they dont like the things i like That's not the reason for my comment. I truly don't understand how after so many years someone "isn't sold" on TypeScript. Sure, you don't have to use it if you don't want to, but if don't see how it's truly essential in current JS development, I don't know what else to assume, other than OP doesn't have enough experience. > it was created by microsoft It was created at Microsft, but it was crated by Anders Hejlsberg who, I'm pretty sure, didn't want to just "create a safehaven to C# and java devs", he was actually solving real problems with JS development, completely orthogonal. You can argue that TS's first syntax was very C/C# inspired, and that Anders also created C#, but that's not what OP meant (or at least how it read).

perrohunter 3mo ago

For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?

lelandfe 3mo ago
If you’re continuing to use the previous version in CI, there’s no reason to not use this locally. It’s a tremendous speed upgrade.
- herpdyderp 3mo ago
  The reason to not use it locally is false negatives or false positives compared to your CI version. Your local tsc will not match the results of your CI tsc.
sheept 3mo ago
It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.
herpdyderp 3mo ago
Depends on your tooling. I can't update yet due to ESLint package dependency mismatches. I'll have to wait for all the ESLint plugins to update. There may also be new failures in your code from the v6 to v7 update. I had only a very minor one though in my initial test.
- dmix 3mo ago
  Eslint is like an anchor on upgrading anything (including Eslint itself). I'll be happy to move on from it.
  - Timon3 3mo ago
    I've been really, really happy with oxlint. It has all the rules I usually need and the configs etc. tend to just work, whereas I don't know how much time I spent getting ESLint to work in slightly more complex repo setups.

fishgoesblub 3mo ago

Are these performance improvements just for transpiling the Typescript to JS, or actually running programs written in Typescript?

tpetry 3mo ago
These are for type-checking. Transpiling takes barely any time.
culi 3mo ago
TypeScript isn't a runtime language

m3h 3mo ago

The speed up numbers based on their testing: Codebase | TypeScript 6 | TypeScript 7 | Speedup ------------|--------------|--------------|-------- vscode | 125.7s | 10.6s | 11.9x sentry | 139.8s | 15.7s | 8.9x bluesky | 24.3s | 2.8s | 8.7x playwright | 12.8s | 1.47s | 8.7x tldraw | 11.2s | 1.46s | 7.7x Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun). Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?

hackerbrother 3mo ago
Do you think Bun's migration was irresponsible?
- ricardobeat 3mo ago
  Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear. Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
  - docmars 3mo ago
    Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
    - 3mo ago

deleted 3mo ago

[deleted]

devtoolsuite 3mo ago

[flagged]

_pdp_ 3mo ago

I've been waiting for this for a long long time. Congrats on the release.

pmkary 3mo ago

Glorious Day!

m_ke 3mo ago

After running out of Fable credits in a day on my max plan I started looking around for ways to trim down my token usage and came to the realization that all of the type spaghetti that opus wrote is probably eating up like 50-70% of my tokens. A clean django project is probably 3-4x less code than the equivalent TS based service. It made me consider dropping strict mode and defaulting to js for most simple things.

jw1224 3mo ago
Interesting, I've come to the opposite conclusion: a lack of types (or types that are only weakly enforced) costs me significantly more tokens in the long-run to maintain, and makes it far too easy for models to silently introduce bugs. I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers. (This would drive me absolutely insane, but my agents get over it pretty quickly!)
IceDane 3mo ago
Why not just do like.. actual engineering, and stay in control of what the LLM builds?
kodama-lens 3mo ago
In a world where code generation is cheap, why use untyped languages? Types add confidence, stricter interfaces, and most likely a better runtime performance.
- m_ke 3mo ago
  With agentic coding the costs of tokens compound with each message / tool call and etc. Having to load in and update large files makes things slower and way more expensive. Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase https://www.databricks.com/blog/benchmarking-coding-agents-d... simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs. PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).

herpdyderp 3mo ago

I'm only seeing a speedup of 4x compared to v6, but I'll take it!

brikym 3mo ago
3 - 3.5x here. I'm very happy with that though.

ksec 3mo ago

I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?

kristianp 3mo ago
Just about every release of go has incremental performance improvements [1]. It's a very stable language, so don't expect anything mind-blowing. For example the latest 1.26 moved a new garbage collector from experimental to production [2]. In the latest compiler they state that: "The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance". [1] https://go.dev/doc/devel/release https://go.dev/doc/devel/release [2] https://go.dev/doc/go1.26 https://go.dev/doc/go1.26
- ksec 3mo ago
  Thanks I have somehow missed this. My mental model is that Go is still 1.5 to 2.5x speed of C hence I asked the question. This is likely wrong number now given so much has been happening without much fanfare. ( or may be I just missed all of it ) Thanks for the link.

dzonga 3mo ago

congrats to the typescript team. I have a longer blog post or audio to post. but in short - the javascript/typescript ecosystem is like working with wood. you can have your cheap, laminate cardboard wood - Ikea type - the code equivalent will be vibe coded apps that are not original. then on the high end - you can have your crafted furniture | wooden skyscrapers - that use custom joinery & lamination techniques using young lumber to make to make beams that are fireproof. you can also have high end stuff in the javascript/typescript ecosystem that uses A.I as one uses powerful machine tools but with crafting in mind. for those that dare to make or dare to do - embrace the typescript|javascript ecosystem.

some-guy 3mo ago

I remember going from Java in IntelliJ straight to TypeScript at work for another project, and I recall how _slow_ everything was in the editor(s). I have been using TypeScript 7 RC and most of my complaints have gone away with regards to speed.

mckee_plus_plus 3mo ago

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.

paustint 3mo ago
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.
silverwind 3mo ago
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.

settled 3mo ago

Great links but unfortunately it doesn't work with ts-jest out of the box, had to do the side-by-side compatibility workaround. Major releases should give more confidence for common tools like testing instead of pointing backwards

Timon3 3mo ago
I don't think it's reasonable to expect the TS team to hold back the release until the ecosystem has caught up.
- settled 3mo ago
  [dead]

austin-cheney 3mo ago

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.

MiTypeScript 3mo ago
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.

gokulrajaram 3mo ago

[flagged]

linzhangrun 3mo ago

Congratulations! Although I'd prefer the C# authors to rewrite it in C# AOT :)

anankaie 3mo ago
Or implement tsaot
- knocte 3mo ago
  Yeah! This way TS at runtime would also benefit from the speedup, not just the compilation.

jeswin 3mo ago

Congrats on launch. The code is beautiful, and the test suite is quite solid. Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts https://github.com/tsoniclang/tsts It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.

lioeters 3mo ago
That tsts project looks very interesting. I suppose there are various practical reasons for doing this. For me I'm just glad to see an easy way to run the newest TypeScript compiler (and I guess type checker?) in the browser. There's an unofficial Wasm build of tsgo/ts7, if I recall was about 12Mb. Another advantage of tsts I imagine is the ease of diving into the compiler internals as it's running (interpreted) instead of a binary distribution, another language (though I like Go), or having to recompile it on every change. Good luck with the project, I'll be keeping an eye on its progress with interest.
- jeswin 3mo ago
  Thanks. The idea is that many projects (including tsts itself) can be run unmodified on a JS runtime, or as a native binary via NativeAOT/C# or Rust.

shafiq235 3mo ago

Its the best thing ever. I have been waiting months for this Thanks to Microsoft for the first - NON SLOP release

zigae 3mo ago

[flagged]

ShinyLeftPad 3mo ago

Does lack of compiler API mean typescript-language-server is not going to play nice with 7.0?

kristianp 3mo ago
https://news.ycombinator.com/item?id=48840113 https://news.ycombinator.com/item?id=48840113 seems to answer that question. I.e. an api for the compiler is being worked on.
- ShinyLeftPad 3mo ago
  Sure but typescript-language-server is different because it's also from MS.
sharlos201068 3mo ago
I remember reading they're rebuilding it to use the same LSP as other languages instead of its custom thing.
- ShinyLeftPad 3mo ago
  it's not? pretty sure I use typescript-language-server as generic LSP from my editor for years

amai 3mo ago

So the compiler written in Go is nearly 10x faster than the old one written in JavaScript

jekuer 3mo ago

TS gained so much more relevance with AI. Hope they do not mess it up!

ramon156 3mo ago

Awesome! Off-topic, can we get something like TS for PHP now? Tools like PHPStan work fine, but I'd love a typed language on top of PHP that can catch a lot of things on compile time. I want to be able to compile my symfony routes, avoiding as much as possible on runtime. I've been thinking about this since 2022 and haven't really gotten further than "Hmm, I would like this". I'm aware that tooling catches most stuff, but being able to shift this even more to the left (compile time) would be great. I'm just very used to Rust, where my hand is being held

Cthulhu_ 3mo ago
Have you considered Hack (https://hacklang.org/ https://hacklang.org/)? it's PHP with types from Facebook, probably the biggest contributor to the PHP ecosystem at the moment. It does need a compiler though, unlike TS where an interpreter can just strip / ignore type annotations. But IMO, a compile step is worth it if you get type assurances in return.

joygqz 3mo ago

[dead]

plasticeagle 3mo ago

I love Typescript, I think it's a fascinating language with a great runtime. It's already very fast to execute, but the compile times have been awful. Especially when you start to run production builds with minification and whatnot. So I'm interested on what exactly has been sped up here. I can see compile times have been, but is that it? I suppose the runtime itself was always native code, and already very fast.

inbx0 3mo ago
What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.
skybrian 3mo ago
The TypeScript compiler is (was) slow, but you don’t need it to minify code. This sounds like some other problem with the tools in your project’s build. (There are faster tools available these days.) A faster type checker will help with performance problems in text editors since type info is needed for a lot of queries.

wartywhoa23 3mo ago

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. ¹https://github.com/Nsttt/typescript-go https://github.com/Nsttt/typescript-go

lelele 3mo ago

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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

sharlos201068 3mo ago
To be fair, this wasn't just rewriting the software, it was translating logic in JS largely one-to-one into Go.

aabbcc1241 3mo ago

I've not figure out how to run typescript script directly with type-checking (in dev mode) with typescript 7. ts-node cannot be used with typescript@7. although node@24 can directly run typescript file, but stripe the types, without type-checking, also it require changing the import path with .ts, and it doesn't support import .tsx files.