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

451–460 of 943 posts

Re: A 10x Faster TypeScript

#451

Post by ggus »

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…

Agree. TypeScript is primarily a programming language. Did they make the language faster? No. Hence, the title is misleading.

Re: A 10x Faster TypeScript

#452

Post by jakelazaroff »

dec0dedab0de wrote: post #196
kaoD wrote: post #10

Earlier quoted context omitted.

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…

“faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript. Just like if you said faster C++ that could mean the compiler runs faster, or the resulting machine code runs faster. Just because the compile target is another human readable language doesn’t mean it ceases to be a typescript program. I didn’t think this particular example was v…

> “faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript.

That still wouldn't make sense, in the same way that it wouldn't make sense to say "Python type hints found a way to automatically write more performant Python". With few exceptions, the TypeScript compiler doesn't have any runtime impact at all — it simply removes the type annotations, leaving behind valid JavaScript that already existed as source code. In fact, avoiding runtime impact is an explicit design goal of TypeScript [1].

They've even begun to chip away at the exceptions with the `erasableSyntaxOnly` flag [2], which disables features like enums that do emit code with runtime semantics.

[1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...

[2] https://www.typescriptlang.org/docs/handbook/release-notes/t...

Re: A 10x Faster TypeScript

#453

Post by uticus »

jodrellblank wrote: post #352
electroly wrote: post #143

Earlier quoted context omitted.

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C# , given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?" C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed. C# has all that stuf…

> "given that C# was famously created by the guy writing the blog post" What is this logic? "You worked on C# years ago so you must use C# for everything"? "You must dictate C# to every team you lead forever, no matter what skills they have"? "You must uphold a dogma that C# is the best language for everything, because you touched it last"? Why aren't you using this logic to argue that they should use Delphi or Turbo…

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course).

So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages.

If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?

Re: A 10x Faster TypeScript

#454

Post by steveklabnik »

uncenter wrote: post #202
eapriv wrote: post #25

It’s not obvious from the text, but the compiler was previously written in TypeScript (which was kind of a strange choice for the language to write a compiler in).

is it not common to write compilers for languages in the language being compiled itself? rust does this i think?

It is fairly common, yes. Sometimes those compilers (or interpreters) aren't the primary implementation, but it's certainly a thing that happens often.

Most of the Rust compiler is in Rust, that's correct, but it does by default use LLVM to do code generation, which is in C++.

Re: A 10x Faster TypeScript

#455

Post by pjmlp »

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…

Apparently not good enough, given the decision to use Go.

Re: A 10x Faster TypeScript

#456

Post by pier25 »

xandrius wrote: post #353
pier25 wrote: post #150

Earlier quoted context omitted.

> sounds like cross platform AOT compiled C# not being mature and performant was a big reason I don't think it was the performance. C# is usually on par or faster than Go. Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.

I never heard C# being fasted than Go, except on certain batched jobs and even there Go can be better.

For example, look at the Techempower benchmarks.

I benchmarked HTML rendering and Dotnet was 2-3x faster than Go using either Templ or html/template.

Etc.

Re: A 10x Faster TypeScript

#457

Post by odyssey7 »

The key:

> immutable data structures --> "we are fully concurrent, because these are what I often call embarrassingly parallelizable problems"

The relationship of their performance gains to functional programming ideas is explained beginning at 8:14 https://youtu.be/pNlq-EVld70?feature=shared&t=522

Re: A 10x Faster TypeScript

#459

Post by [deleted] »

christianqchung wrote: post #238
Starlord2048 wrote: post #211

[flagged]

This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.

[deleted]

Re: A 10x Faster TypeScript

#460

Post by dboreham »

dagw wrote: post #102
AshleysBrain wrote: post #64

Earlier quoted context omitted.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS/JS codebase? [1] https://www.construct.net/en

Why is the TypeScript team moving to an entirely different technology A few things mentioned in an interview: Cannot build native binaries from TypeScript Cannot as easily take advantage of concurrency in TypeScript Writing fast TypeScript requires you to write things in a way that isn't 'normal' idiomatic TypeScript. Easier to onboard new people onto a more idiomatic codebase.

The message I hear is: don't use JS, don't use async. Music to my ears.
Post reply on HN