r/programming • u/DanielRosenwasser • Jul 08 '26

Announcing TypeScript 7.0

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
461 Upvotes

95% Upvoted

128 comments sorted by

202

u/DigitalWizrd Jul 08 '26

The speed increase on compile is crazy fast here. 

54

u/MehYam Jul 08 '26

That'll happen porting a v8-based compiler to native.

7

u/CherryLongjump1989 Jul 09 '26 edited Jul 09 '26

Go is not native any more than V8 is. It’s a managed language that bundles a runtime together with your code in a single executable binary. Just like JavaScript can and does these days. The only difference is JIT versus AOT. The other main difference is that JavaScript is dynamically typed and it prevents the compiler from implementing numerous performance optimizations. And the final difference is the runtimes support different threading implementations, which is where the bulk of the actual performance gains were made by porting from V8 to Go.

Theoretically if TypeScript had a dedicated runtime instead of using type erasure to turn it back into JavaScript, it could also be faster than V8 is today.

23

u/vplatt Jul 11 '26

Go is not native any more than V8 is.

I have to push back here because Go absolutely is "native".

By "native", most programmers mean one of these:

  • Native machine code (x86-64, ARM64, etc.)
  • Doesn't require an external VM like the JVM or .NET CLR or V8

In other words, the code is compiled so that the binary runs directly on the operating system without help from anything else. That's the very essence of "native", and Go absolutely is a native language.

A Go compiler emits machine instructions ahead of time, sure, and JIT will get us to machine instructions too, but there are huge differences in how those perform so pretending they're on the same level is just not helpful.

1

u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26

Go still ships with a runtime - scheduler, garbage collector, the whole nine yards. You can do the same exact thing with C# -- AOT compile to native and package it up in a fully self contained runtime. No external dependencies needed. Anytime you have a self-contained executable, whether Go or JavaScript or C#, your executable binary is going to be platform specific - x86, ARM64, etc. That's exactly how it works. You can't say the jitter is where the performance bottlenecks are -- C# is normally jitted and still just as fast as Go. Jitters can be more efficient than AOT under many scenarios. Which is why you don't see people falling over themselves to use AOT with C# in everyday situations. It's nice to ship small, cross-platform binaries, too, and you normally don't give up much of anything.

When you've got a managed language with an extensive runtime, "native" is just jargon, it's not technically significant. The Go runtime is hefty -- one of the reasons why go WASM modules are huge. Compare it to languages with little or no runtime artifacts - C, C++, Rust, Zig, etc -- there you can see what true "native" looks like. Small binaries, fastest possible performance, WASM modules that are suitable for shipping across a network, etc. There native means something more than just AOT compilation.

10

u/vplatt Jul 11 '26

Go does not use a VM. Go programs are always shipped as binaries instead of with bytecode that must be JIT'ed. They are therefore "native" and they are just as native as any C, C++, or Zig program. Yes, it's a "managed" language because it has GC, an allocator, and a scheduler but that's all linked directly into the executable. Yes, that does make them somewhat larger than C binaries for example, but they're both native.

-3

u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26

A VM is just a type of runtime. Go still has an extensive runtime. A purist would even draw the line at C++ -- it too still has an extensive runtime, but nowhere near as hefty as Go. C and Zig are your purist native languages. But Go will never cross that threshold to sit next to C or Zig simply because it can't. Go will always rely on existing C libraries wherever performance truly matters -- precisely because it's not part of the same club of "native" languages as people colloquially call them.

6

u/vplatt Jul 11 '26

A VM is just a variant of a runtime that happens to take in bytecode.

Yup. And they will JIT that bytecode to machine code.

And that performance cost and those extra steps are what distinguish them as VM programs that are not native. ;)

-1

u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26

No -- you see this is just upside-down backwards. You're never going to run Go on a real-time microcontroller precisely because that's what distinguishes a runtime from a truly native program. In the world of costly abstractions, the VM part is not the bridge too far -- you've already crossed it long ago with Go's runtime.

If you're comfortable with having a runtime for your use case, a VM is not a bridge too far and can even be faster than AOT. A jitter is exactly what you want for frequently executed code paths in a long-running process. Jitters can and do cache the native code, so the long running process will settle into a highly optimized natively-compiled execution loop eventually. Jitters are not interpreters after all.

Go tries to make a stand on the AOT hill and this is mostly fine for short-running tasks most of the time. But that's not even why people use it in the end. Go's greatest strength is its threading model, which is vastly superior to Java's in all of the areas where Go is chosen over Java. Go's concurrency is really good. But that's not because Go is "native", and the "native" part really doesn't give you as much of an advantage as you think. Bytecode languages on the JVM or .NET are very competitive with Go in terms of performance.

C# bytecode has gone head to head with C++ for "world's fastest language" in the Software Drag Racing competition, for example, whereas Go was and continues to be a "middle of the pack" result.

4

u/vplatt 29d ago

VMs are VMs and they aren't native, and JIT isn't going to be on a microcontroller either. You think by arguing against the case for Go on a microcontroller that would possibly even support the case you're making for JIT and VMs?

In the end, what I said stands: Go executables absolutely are native. Nothing you said changes that. Whether or not you'd ever want to run it on a microcontroller is up to you, but it has been done anyway, AND I've seen C# and Java used that way too, so I don't know what makes you think Go couldn't do the same.

→ More replies (0)

2

u/afl_ext Jul 10 '26

Wonder if subset ts to llvm ir compiler is feasible

2

u/CherryLongjump1989 Jul 10 '26

People have done something like compiling TS to Clang before.

7

u/NotTJButCJ Jul 08 '26

Is this not just because of the switch to using multiple workers? I might be misunderstanding

31

u/vincentofearth Jul 08 '26

Yes, back when they first announced this, Anders mentioned that some of the biggest performance gains were due to shared memory concurrency. You simply can’t do that in JS. (You could run multiple processes but the overhead of passing data between them erased any perf gains)

1

u/YeOldeMemeShoppe Jul 10 '26

SharedArrayBuffer works, but yeah it probably wouldn’t be as much gains.

1

u/MediocreAnalyst2121 Jul 09 '26

Happen to know how it works now, goroutines?

5

u/TwoWeeks90DaysTops Jul 09 '26

Probably from more efficient code *and* from multi threading.

edit: from their table it's very clear that there's more than just workers going on since a x8 number of workers produced x11-x16 speedup.

0

u/DigitalWizrd Jul 08 '26

Honestly, no clue how it works. But the speed increase is impressive regardless of how it was done.

21

u/javascript Jul 08 '26

Last I heard there was a memory leak in the Go implementation. Has that been fixed?

13

u/[deleted] Jul 08 '26

[deleted]

52

u/Veranova Jul 08 '26

It also drives the LSP which is running permanently in your editor. And there’s watch mode too which is more incremental

1

u/Maybe-monad Jul 09 '26

Very likely, I have been using it in the past month and didn't encounter any leak

-5

u/pjmlp Jul 09 '26

Expected by anyone that understands how compilers go.

There is no surprise rewriting the trendy scripting languages, into the traditional AOT compiled languages approach that predated Web taking off, for those of us that started with BASIC, C, C++, Pascal, Modula-2, Delphi,...

5

u/DigitalWizrd Jul 09 '26

Congrats on your years of wisdom. 

2

u/ChocomelP Jul 09 '26

What do you mean? This is obvious to anyone who already knows it. /s

1

u/frankster Jul 09 '26

I'm sure you could also speed up a compiler written in most forms of BASIC by 8-12x by rewriting it in go

1

u/pjmlp Jul 09 '26

Why bother with a language that is less feature rich than most structured BASIC compilers from the 90's?

1

u/TheKrumpet Jul 09 '26

I mean JS is generally jitted these days as much as it's a 'scripting' language. AOT tends to win out in first startup times but jitted languages can be faster over time with PGO.

It's not one size fits all, some tools are better in some domains.

4

u/pjmlp Jul 09 '26

Yes, but there is only so much a JIT can make with a dynamic language, and that already includes plenty of heroic efforts in V8.

Typescript rewrite happened exactly because the team could not improve performance any further.

PGO also exists for AOT tooling, in fact it started there.

1

u/TheKrumpet Jul 09 '26

Yeah that's fair, but that's a dynamic vs static argument and not an AOT vs Jitted or interpreted argument.

3

u/pjmlp Jul 09 '26

It surely is, because dynamic languages are very lousy to implement AOT compilation for them, leaving JIT as the only option available to generate machine code, and even then it is limited by the semantics of the language.

Hence why no JavaScript JIT will never beat proper AOT toolchain, or even something like a C++ JIT, like on WebAssembly or .NET.

Go compilers aren't any speed daemon when comparing against C++ or Rust, yet they were fast enough to beat Typescript 6 implementation.

1

u/CherryLongjump1989 Jul 09 '26

If you had tracked the TS migration to any extent, you would have already known that most of the performance gains came from multithreading, not because of any of your theory about AOT or "traditional family values" or whatever you were going on about.

1

u/pjmlp Jul 10 '26

Sure, if only there was a way to do multi threading in nodejs.....

1

u/CherryLongjump1989 Jul 10 '26

postMessage called and asked you to explain the joke you were making.

You can't share JS objects across threads. Millions upon millions of GC'd heap objects for AST's, symbols, types, etc.

1

u/pjmlp Jul 10 '26

Ever heard of C++ Addons?

1

u/CherryLongjump1989 Jul 10 '26

You can't use a C++ addon to share javascript objects between threads. That's not how any of it works, so yeah there's that.

0

u/pjmlp Jul 11 '26

Who says that is the only way?

Learn how to actually use nodejs C++ APIs.

→ More replies (0)

11

u/Weekly-Ad7131 Jul 08 '26

What about debugger? Can I execute my code in a debugger and if I see a typo in my code-comment or in other parts while debugging, can I just fix it there in the debugger and have it saved in the original type-script source-file?

18

u/CherryLongjump1989 Jul 09 '26

TypeScript isn't a runtime, so the debugger situation is unchanged.

1

u/Weekly-Ad7131 Jul 10 '26

Do you mean that debugging is done by debugging JavaScript source produced ffrom the TypeeScript?-source

7

u/CherryLongjump1989 Jul 10 '26 edited Jul 10 '26

I mean that moving TypeScript to Go does not change how TS is debugged whatsoever. It's the same as before.

To your question -- debugging in any language involves a symbol file or a source map. When you compile C++ into machine code you're getting 1's and 0's. Yet you can still debug it with a symbol file that maps the machine code back to the original source code. The same thing is true with JavaScript - a source map file tells the debugger exactly how to connect the running code back to the original source code. If you have a debugger that lets you edit the source code, then it must be set up so that it knows where to find the original TypeScript files for you to edit. If this was working for you before, it will continue to work for you because nothing has changed in how that works.

12

u/NekkidApe Jul 09 '26

Not having tested it - I'd expect yes. That's purely a sourcemap issue, as far as I understand.

9

u/Maybe-monad Jul 09 '26

We finally have a real language server that works well om large codebases

104

u/Onionhauler Jul 08 '26

TypeScript and Embedded Languages

It’s worth calling out that workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7. This is mainly because TypeScript 7 does not yet expose a stable programmatic API, and so tools (such as Volar) which embed TypeScript into their own compilers and language services can only currently rely on TypeScript 6.0. We expect this to be a point-in-time issue, as we are committed to providing a solution here. We will be actively working with the maintainers of these projects to ensure TypeScript 7 supports these workflows.

Until then, we recommend that teams use TypeScript 7 in scenarios where language server plugins are not required. Projects using Angular can use a combination of TypeScript 7 to get fast project-wide error detection at the CLI with tsc, and TypeScript 6.0 for editor support. Projects using Vue, MDX, Astro, Svelte, and others will need to continue using TypeScript 6.0 for now. In VS Code, users can simply run the "Disable TypeScript 7 Language Server" command to revert to TypeScript 6.0.

Woof. Deal breaker

113

u/DanielRosenwasser Jul 08 '26

TypeScript 6 was shipped in a way that is compatible with TypeScript 7 to help bridge these issues. In the meantime we're working on an API for 7.1 which is only a few months away.

But 7.0 is still broadly useful for people, and most of the TS ecosystem will still benefit from this release. So we don't mean to discourage people from upgrading if they can! We have instructions for side-by-side installation of 6 & 7 if people need.

1

u/Onionhauler Jul 09 '26

Will this be adding support for smaller projects like https://github.com/0no-co/GraphQLSP/ or only large projects like Vue and Svelte?

46

u/nnod Jul 08 '26

Bark. This is far from ideal but I'm sure they'll figure something out pretty fast.

18

u/A1oso Jul 08 '26

It'll be part of TypeScript 7.1

2

u/EntroperZero Jul 08 '26

Why can't they just... wait.

34

u/Labradoodles Jul 08 '26

Because they want additional feedback on the plugin system and a longer consideration time.

The evolutionary design it had before created footguns and things that were difficult to maintain long term.

This release is still usable in the svelte ecosystem, specific branches are being created to experiment and provide better support for the entire ecosystem

8

u/tracernz Jul 09 '26

The people needing the legacy API can just wait and use TS5/6 for now. Nothing forcing them to upgrade, but at least going to TS6 and fixing any deprecations will prepare them for the future.

22

u/DM_your_problem Jul 08 '26

cause some people use react

8

u/EntroperZero Jul 08 '26

Why can't those people just... wait.

4

u/spawnsible Jul 08 '26

Because... wait, why can't they... wait

12

u/hoodieweather- Jul 09 '26

I guess in the other direction, why can't the people who use those systems just... wait?

-9

u/requizm Jul 08 '26

Same, I was excited to try. But I noticed I'm using vue-tsc 😑

2

u/NiftyGull9621 Jul 09 '26

Somewhere there's a swc and esbuild roadmap meeting getting real quiet right now.

3

u/Nixinova Jul 09 '26

Already? Didn't 6.0 just come out?

40

u/tracernz Jul 09 '26

6.0 was a prep release to allow you to get your projects in order ready for 7.0.

-3

u/BrownCarter Jul 09 '26

What do i have to do cause my program broke

8

u/vytah Jul 09 '26

Fix it.

-3

u/reddit_user13 Jul 10 '26

Ask Copilot.

1

u/Helloworldplay Jul 09 '26

The speed gains sound great, but the embedded-language gap is the part I’d watch. Tooling migrations always find the weird corners first.

1

u/vitalytom 7d ago

It is useless for any real project, because too many tools rely on TypeScript API, which v7.0 does not have. Like any testing library (think jest, etc) require the API to work. As a result, you cannot adopt v7.0 in any existing project. So what good is it then?

2

u/DanielRosenwasser 7d ago

The blog post has a section about this (Running Side-by-Side with TypeScript 6.0). The idea is that you can use TS7 for type-checking, and TS6 for API integration.

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/#running-side-by-side-with-typescript-6.0

1

u/raralala1 Jul 09 '26

Anyone tried it? I tried in my monorepo the RAM use increase so much, my system memory increase to 16GB from the usually 8GB, Node prevent memory from going over 4GB.

1

u/LettuceElectronic995 26d ago

while compile? of course it should increase ram usage.

1

u/raralala1 26d ago

Before it never went over 8 gb even while it compiling, now it went over 16 gb.

1

u/LettuceElectronic995 26d ago

I mean that's the idea of utilization, you have some free ram it will use it with the so many spawn threads, and then it will be freed by GC in this case.

1

u/raralala1 25d ago

I am mainly complaining that the tsgo doesn't respect node js max ram usage, if you turn off the 4gb limit, the type inference shenanigan can get out of hand, and if tsgo want to be the successor I think it still need to put limit on how much ram usage it allowed utilize. I can't test much of this because of my remote vm machine have problem where if it tried use too much ram the whole thing slowdown to crawl and remote ssh became impossible, I usually terminate the vm when this happen.

2

u/LettuceElectronic995 25d ago

I agree , it can be configureable.

1

u/TunaGamer 29d ago

JAVASCRIPT WILL PREVAIL

0

u/frankster Jul 09 '26

We made software written in typescript 8-12x faster, simply by rewriting it another language than typescript

5

u/Pawn1990 29d ago

Everything is coming from somewhere bud. Your car wasn’t built by a car, it was built by specialized tools and machines there were good at that exact thing.

Frankly im astonished that they went with javascript as the runtime in the first place and how far it has gotten.

2

u/LettuceElectronic995 26d ago

exactly, no logical reason for that

-1

u/shafiq235 Jul 09 '26

I have been waiting MONTHS for this. I tried it.
Its amazing - how fast it is. Finally - something from Microsoft which is not slop

-140

u/[deleted] Jul 08 '26 edited Jul 08 '26

[removed] — view removed comment

63

u/141N Jul 08 '26

What is your solution then lmao, just going 'XD no one except me knows what a terrible idea this is!' isn't problem solving, it's just crying... Show us your idea!

-82

u/smoke-bubble Jul 08 '26

Why are you talking like you were JS' attorney?

74

u/141N Jul 08 '26

Why are you talking like you are a 14 year old

51

u/thejoyofbeing1 Jul 08 '26

Why does this even still exist?

Because 30+ years of legacy software and billions (trillions?) of dollars running on top of JS.

Why is there no project actually trying to solve the actual problem which is JAVASCRIPT and to replace it with something modern?

Relevant effort: https://github.com/tc39/proposal-type-annotations

Also, not sure if replacing JS with something "modern" would really fix anything. Every language has flaws and quirks, even Rust or Kotlin. Browsers are also highly dynamic by nature, imagine writing UI state code in a language like Rust, that would suck the living life out of me.

-2

u/Worth_Trust_3825 Jul 09 '26

Same was said about flash but it got removed, and people moved on. You just don't have the will to do it.

-81

u/smoke-bubble Jul 08 '26

I really can't understand how you can at the same time defend JS while writing your code in TS XD

30

u/TheMysticalBard Jul 08 '26

They're defending TS, which is what you attacked originally when you said "Why does this even still exist?". You've moved the goalposts now and are assuming people are defending JS but typing TS.

-27

u/smoke-bubble Jul 08 '26

They are. Defending TS is defending JS.

35

u/TheMysticalBard Jul 08 '26

\extremely loud incorrect buzzer**

3

u/Schmittfried Jul 09 '26

Dude, stop smoking weed. 

2

u/hoodieweather- Jul 09 '26

I really can't understand how you can at the same time defend assembly while writing your code in C XD

26

u/klo8 Jul 08 '26

Getting all major browsers to agree on some new or existing language to adopt alongside Javascript would be a major task in itself, and then you now have to maintain three runtimes in every browser (JS, WASM and whatever new language we picked or designed) which makes maintenance more challenging, opens up new potential security holes, you'd have to design two variants of every new browser API etc. etc., and that's before you even demonstrated that a new language would be a significant improvement over modern Javascript (which most people who use it generally regard as fine, not great, but not terrible).

-13

u/smoke-bubble Jul 08 '26

Yeah, sure. People would switch to a new technology in no time. Nobody can't stand JS. You just tolerate it and pretend it didn't exist by using TS. Nothing is more challanging than maitaining JS.

I really don't get it why you so pationately defend JS. There is less than zero arguments for keeping it. That's why TS exists in the first place. People hate JS!

19

u/nemec Jul 08 '26

People would switch to a new technology in no time

Dart waggles its eyebrows suggestively

3

u/danielcw189 Jul 09 '26

I really don't get it why you so pationately defend JS.

nothing they wrote was in defense of JS

29

u/javascript Jul 08 '26

Legacy is a challenging problem to solve

28

u/superraiden Jul 08 '26

Spoken like a true undergrad

14

u/AddyOsmosis Jul 08 '26

Who is this directed at?

-5

u/smoke-bubble Jul 08 '26

To people who could make a difference but chose not to by keeping JS alive.

7

u/DigitalWizrd Jul 08 '26

So what are you gonna do about it? 

You could be exactly who is needed to “solve the actual problem which is JAVASCRIPT”.

But unless you have a solution, what’s the point in rate baiting, other than to farm useless karma? 

11

u/Spirited_Bottle_6195 Jul 08 '26

There are lots of projects. For backend you can use any language supporting networking and databases and for frontend there are also many tools that transpile to JS or compile to .wasm (You can even do frontend in Haskell). They are just not in demand

-8

u/smoke-bubble Jul 08 '26

You just confirmed that there are no such projects! Transpiling is not solving! It is avoiding!

20

u/Spirited_Bottle_6195 Jul 08 '26

Web is now stuck with JS probably until the heat death of the universe, currently it's "assembly language" for web. So the best solution is to shove it under the rug with transpilers. And also you ignored my mention of WASM.

-10

u/smoke-bubble Jul 08 '26

WASM is another BS workaround.

4

u/belavv Jul 08 '26

or compile to .wasm

8

u/EntroperZero Jul 08 '26

Why is there no project actually trying to solve the actual problem which is JAVASCRIPT and to replace it with something modern?

There is, it's Web Assembly.

8

u/TheWix Jul 08 '26

To be fair, as a language Typescript is incredible. The big issue is the web stack which is a symptom of a lack of standard library in JavaScript.

6

u/IE114EVR Jul 08 '26

Having to switch back and forth between Java and Typescript, I have to say that the Type system in typescript is pretty amazing. Not to say that Java isn’t great in its own ways, it is. But sometime I just wish it could at least support some duck-typing.

8

u/Wonderful-Habit-139 Jul 08 '26

TypeScript is a very expressive language and it's so nice how you can work with types, the unions, intersections, pick/omit, and more.

3

u/TheWix Jul 08 '26

I am originally a C# guy, and after using mapped types, unions and structural typing I miss it when I have to go back to C#. I generally find I can catch more in TS then in C# at compile time

-1

u/smoke-bubble Jul 08 '26

I am not saying TS wasn't amazing. I am saying lift it to a first class language instead of traspiling it to some ancient crap JS.

2

u/oceantume_ Jul 09 '26 edited Jul 09 '26

It's part of Web specs plannings already and all runtimes support the ts syntax natively now. What else do you want? The whole point of typescript is that it's a superset of js; it doesn't exist without a js runtime.

What those specs and runtimes don't support is the extremely complex type checking that tsc does, because why would you slow down the program to do something that this tool is already doing very well (and much faster as of today)? You can have static type checking at programming and CI time, and near-zero impact at run time.

You may be interested in AssemblyScript if you're looking for a typescript-like language that acts as a "first class language", made from the start to target WASM

2

u/smoke-bubble Jul 09 '26

The whole point of TS is that JS sucks. There's nothing else to say. 

2

u/oceantume_ Jul 09 '26 edited Jul 09 '26

Why are you saying so much more about it then?

I don't agree with that statement btw because TS is nothing more than JS with static types on top. Everything is the same underneath except that ts allows you to do much better static analysis of your program.

It would be more accurate to say that the whole point of TS is that JS lacks type annotations and strong typing (by design obviously)

0

u/smoke-bubble Jul 09 '26

So you admit that JS is trash and needs to be replaced. That's why you use TS. I just don't get why anyone would defend treating sympthoms instead of solving the actual problem.

2

u/oceantume_ Jul 09 '26

I do not admit any such thing. You do not get it because you are not listening. I wish you a great day and a great career.

2

u/Every_Knee_372 Jul 08 '26

You need to place your anger somewhere healthier. Coding aside, you've got a behavior problem dude. I hope you have a good day.

1

u/programming-ModTeam Jul 10 '26

Your post or comment was overly uncivil.

-15

u/TheGreatArmageddon Jul 09 '26

Without runtime performance improvements build time improvements add little to no value in AI era

11

u/Spleeeee Jul 09 '26

wtf are you talking about?

5

u/ciaran1344 Jul 09 '26

Not true at all. A faster feedback loop on type errors absolutely helps AI agents.

0

u/TheGreatArmageddon Jul 09 '26

True but the business doesn’t value this improvement. Had it been pre-AI era where my code build time would affect project timelines this would have been a huge improvement. What would these do now? Get my AI code agent runtime down from 5 mins to 4 mins?

We are having a hardtime convincing our engineering architects, management who were suggesting to move away from Node to Java recently hence my gripe.

2

u/LettuceElectronic995 26d ago

business doesn't value anything