Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

431–440 of 943 posts

Re: A 10x Faster TypeScript

#431

Post by dist1ll »

jjice wrote: post #31
pjmlp wrote: post #12

Even though I have my considerations regarding Go, I love that they picked Go instead of the fashion to go Rust that seems to be the norm now. A compiled managed language is much better approach for userspace applications. Pity that they didn't go with AOT compiled .NET, though.

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

Dealing with references you typically find in a compiler is not a problem for Rust. Arena allocation and indices are your friend.

Re: A 10x Faster TypeScript

#432

Post by electroly »

vessenes wrote: post #248
electroly wrote: post #176

Earlier quoted context omitted.

This is Anders Hejlsberg , the creator of C# , working on a politically important project at Microsoft . That's what I mean by political benefit. The larger open source world doesn't matter for this decision which is why this is a simple announcement of an internal Microsoft decision rather than an invitation for comments ahead of time.

I’m sure Microsoft’s strategy department would disagree with you. As a c# devotee - I get that you’re upset. And you may want to update your priors on where c# sits in Microsoft’s current world. But I think it’s a mistake to imagine this isn’t a well reasoned decision.

They can disagree if they want but as a career-long Microsoft developer they can't fool me that easily. I'm not even complaining, I'm just stating a fact that high-level steering decisions like this are made in Teams meetings between Microsoft employees, not in open discussion with the community. It's the same in .NET, which is a very open source project whose highest-level decisions are, nonetheless, made in Teams meetings between Microsoft employees and then announced to the public. I'm fine with this but let's not kid ourselves about it.

That said, I must have misstated my opinion if it seems like I didn't think they have a good reason. This is Anders Hejlsberg. The guy is a genius; he definitely has a good reason. They just didn't say what it is in this blog post (but did elsewhere in a podcast video linked in the HN thread).

Re: A 10x Faster TypeScript

#433

Post by airforce1 »

nine_k wrote: post #380
maxloh wrote: post #125

Earlier quoted context omitted.

Maybe they'll also be distributed in WASM too, which is easier to be integrated with JavaScript codebases.

Would running WASM be any faster than running JS in V8?

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing.

I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been very difficult for me to even get parity with vanilla JS performance. There is supposedly a way to use a subset of go with llvm for faster wasm, but I haven't tried it (https://tinygo.org/).

I'm hoping that Microsoft might eventually use some of their wasm chops to improve GO's native wasm compiler. Their .NET wasm compiler is pretty darn good, especially if you enable AOT.

Re: A 10x Faster TypeScript

#434

Post by maxloh »

kaoD wrote: post #10
pseudopersonal wrote: post #8

The post title is a bit misleading. It should say a 10x faster build time, or a 10x faster TypeScript compiler . tsc (compiler) is 10x faster, but not the final TS program runtime. Still an amazing feat! But doom will not run faster "To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by…

To clarify why it's actually not that ambiguous: TS is not (and does not have) a runtime at all. Even TS-first runtimes like Deno are (1) not TS but its own thing and most importantly (2) just JS engines with a frontend layer that treats TS as a first-class citizen (in Deno's case, V8). It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further (e.g. by proving that a functi…

> It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further.

Yeah, that exists. AssemblyScript has an AOT compiler that generates binaries from statically typed code.

Re: A 10x Faster TypeScript

#435

Post by airforce1 »

darthrupert wrote: post #395

This kinda begs the question: should we port all backend Typescript code to Go (or Rust) to get a similar runtime performance improvement? Is Typescript generally this inefficient?

If your backend is JS and it's too slow for you, then obviously porting it to a machine code binary will speed it up significantly. If you are happy with your backend performance, then does it matter?

Re: A 10x Faster TypeScript

#436

Post by zigzag312 »

cardanome wrote: post #383
fabian2k wrote: post #309

Earlier quoted context omitted.

C# can create single-binary executables, even without native AOT.

They are still going to significant bigger than the equivalent golang binary because of the huge .NET runtime, no?

https://github.com/MichalStrehovsky/sizegame

C#: 945 kB

Go: 2174 kB

Re: A 10x Faster TypeScript

#437

Post by kansface »

gwbas1c wrote: post #337

This is frustrating: > The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase. > While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing T…

I lived and worked through the Python 2->3 fiasco, working on a Python library that had to run on both versions. I have since abandoned the language. Python3 was both slower and and not backwards compatible whereas TSC 7 is 10x faster and uses half the memory. I'm not worried.

Re: A 10x Faster TypeScript

#438

Post by zozbot234 »

airforce1 wrote: post #433
nine_k wrote: post #380

Earlier quoted context omitted.

Would running WASM be any faster than running JS in V8?

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing. I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been ver…

I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.

Re: A 10x Faster TypeScript

#439

Post by maxloh »

haxiomic wrote: post #397

Sounds like they're automatically generating Go code from ts in some amount [0]. I wonder if they will open the transpilation effort, in this way you'd create a path for other TypeScript projects to generate fast native binaries Opened discussion [1] - [0] https://github.com/microsoft/typescript-go/discussions/410 - [1] https://github.com/microsoft/typescript-go/discussions/467

It seems that they port the code manually, probably with the help of LLMs.

https://github.com/microsoft/typescript-go/commits?after=dad...

Re: A 10x Faster TypeScript

#440

Post by maxloh »

zozbot234 wrote: post #438
airforce1 wrote: post #433

Earlier quoted context omitted.

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing. I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been ver…

I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.

Yeah. If I remember it correctly, you need to compile the GC to run on WASM if the GC extension is not supported.
Post reply on HN