[pseudopersonal]

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 10x, and substantially reduce memory usage."

[kaoD]

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 function diverges) but to my knowledge they currently don't and I don't think there's any in the works (or if that's even possible while maintaining runtime soundness, considering you can "lie" to TS by casting to `unknown` and then back to any other type).

[dec0dedab0de]

“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 very ambiguous because a general 10x speed up in the resulting JS would be insane, and I have used typescript enough to wish the compiler was faster. Though if we’re being pedantic, which I enjoy doing sometimes, I would say it is ambiguous.

[jakelazaroff]

> “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...

[jessekv]

> Python type hints found a way to automatically write more performant Python

I get your point, but... this is exactly the premise of mypyc ;)

[pcthrowaway]

But typescript isn't a minifier or an optimizer. No part of typescript compiles it to anything that looks significantly different (besides enums).

Sure, lots of build tools do this, but that's not Typescript.

With very few exceptions, Typescript is written so that removing the Typescript-specific things makes it equivalent to the Javascript it transpiles to.

[pseudopersonal]

Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor?

https://betterstack.com/community/guides/scaling-nodejs/node....

[fastball]

Those are javascript runtimes, not TypeScript runtimes. The point stands.

If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).

[Izkata]

I thought the title was announcing someone created a Typescript runtime. It is misleading.

Preact was "a faster React", for example.

[zem]

if typescript code execution got that much faster it might be a reason for someone to look into the language even if they knew nothing about it.

[timeflex]

There are plenty of other reasons to consider TypeScript, but again, what code execution are referring to? The V8 JavaScript engine?

[zem]

that's not the point I was making - gp was wondering why someone who didn't even know typescript compiled to javascript and ran atop a javascript engine would care that it had gotten 10x faster.

[alabastervlog]

From the title, my initial assumption was someone wrote a compiler & runtime for typescript that doesn't target javascript, which was very exciting. And I do work with typescript.

[internetter]

> Without clicking the link, you wouldn't know if it's about a compiler or a runtime

I mean I think generally you’d want to click the link and read the article before commenting

[depr]

It has become a sport here to criticize titles for not explaining any random thing the commenter doesn't know. Generally these things are either in the article or they are very easily findable with a single web search.

[jilles]

If you have to explain why something is not ambiguous it is by definition ambiguous.

[hoten]

Maybe they aren't the audience. I don't see how this is ambiguous to anyone that actually uses typescript

[01HNNWZ0MV43FF]

It was ambiguous to me. I've used TS a few times over the years, so I thought "native TypeScript compiler" meant AOT TS, not a TS compiler written in Go

[owebmaster]

deno runs typescript and it won't run 10x faster. It is ambiguous.

[dwaltrip]

It seems Deno compiles typescript to JS just like everyone else.

https://docs.deno.com/runtime/fundamentals/typescript/

[totallykvothe]

No. Ambiguous means that a statement has many possible meanings, not simply that something might be confusing.

[refulgentis]

I'm a bit confused:

- It's not ambiguous because they mean $X.

- It is ambiguous because it has many possible meanings.

- It is not ambiguous because it has many possible meanings

[jzackpete]

that would imply the existence of an objective authority on the meaning of the statement, which is debatable

[pzo]

there is static hermes from Meta that do AoT compilation to native so I find it actually ambiguous. For a second I thought they did a compiler instead of transpile r.

[maxloh]

> 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.

[crabmusket]

AssemblyScript is a very limited subset of the language though.

[seanmcdirmid]

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

Typescript's type system is unsound so it probably will never be very useful for an optimizing compiler. That was never the point of TS however.

[xanth]

Unfortunately many TS users have a surface level understanding of TS leading them to believe that TS is "real"

[pas]

I use TS a lot and still assumed they are embarking on a native runtime/compiler whatever epic journey.

[fabian2k]

I don't think this is misleading for anyone familiar with Typescript. Typescript itself has no impact on performance, and it is known that the compilation and type-checking speed is often a problem. So I immediately assumed that it was about exactly that.

[hexomancer]

When I read the title I thought maybe they implemented a typescript to binary (instead of javascript) code compiler that speeds up the program by 10x, it would also have the added benefit of speeding up the compiler by 10x!

I don't think that is too far fetched either since typescript already has most of the type information.

[gr__or]

I can think of a DOOM that WILL run faster…

https://youtu.be/0mCsluv5FXA

[pseudopersonal]

Ah thanks! I didn't realize there was a Doom running on the TS type system. I stand corrected

[nonethewiser]

That is a really funny coincidence. Of all the examples you could have picked...

[chamomeal]

lol it just “released” recently. Like in the last couple of weeks. It shook the typescript world.

It’s been a crazy couple of weeks for TS!!

[ggus]

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

[hansifer]

That's debatable. I think most people that work with TS see it as a syntax extension for JS. Do you think JSX is a programming language?

[mmcnl]

For anyone who uses TypeScript on a daily basis it's not ambiguous at all. Everyone who works with TS knows the runtime code is JavaScript code that is generated by the TypeScript compiler. And it's also pretty common knowledge that JavaScript is quite fast, but TS itself is not.

[alpaca128]

And if this post was about a TS compiler that emitted x86 executables you would be wrong and find out that it is indeed ambiguous.

[c-hendricks]

Why would a hypothetical "tsx86" project write an article titled "10x faster typescript" instead of "10x faster binaries with tsx86 2.0"

If you have to invent things for something to be considered ambiguous, is it really ambiguous?

[Etheryte]

I don't think it's misleading at all, because you can't run Typescript. Typescript is either compiled, transpiled or stripped down into another language and that's what gets run in the end.

[alpaca128]

You can't run Java either as it's compiled to bytecode, yet when someone says "we made Java 10x faster" you wouldn't assume that just the compilation got faster, right? When people market Rust projects as blazingly fast nobody assumes it's about compilation, in part because a blazingly fast Rust compiler would be a miracle. Outside of this comment section people have always been using a programming language name for this because everyone knows what they mean.

It would be possible that MS wrote a TypeScript compiler that emits native binaries and that made the language 10x faster, why not?

[wendyshu]

Sure you can run Typescript. It's a programming language, someone could always write an interpreter for it.

[Etheryte]

You could, but currently I'm not aware of any widely used options. Both Deno and Node turn it into Javascript first and then run that.

[zamadatix]

You could make the same argument of anything but bytecode and even then some would debate if it's really running directly enough on modern CPUs. In the end it still remains that you have the time it takes to build your project in a given language and the runtime performance of the end result. Those remain very useful distinctions regardless of how many layers of indirection occur between source code and execution.

[Etheryte]

The difference here is that with Typescript, you're not really measuring Typescript's performance, but whatever your output language is. If transpile to Javascript, you're measuring that, if you output Wasm, you measure that, etc, and the result isn't really dictated by Typescript.

[zamadatix]

Transpiling isn't the only possibility to run TypeScript code, it's just the way to do it right now. A long time ago interpreting was the most common way to run JavaScript, now it's to JIT it, but you can also compile it straight to platform byte code or transpile it to C if you really want. That you could transpile JavaScript to C doesn't mean all ways of doing it would be equally performant though.

Transpiling in itself also doesn't remove the possibility of producing more optimized code, especially if the source has more information about the types. The official TypeScript compiler doesn't really do any of that right now (e.g. it won't remove a branch about how to handle a variable if its type equals a number even if it has the type information to know it can't have been set to one). Heck, it doesn't even (natively, you can always bolt this on yourself) support producing minified transpiled code to improve runtime parsing! In both examples it's not because transpilation prevents optimization though, it's just not done (or possibly worthwhile if TS only ever targets JS runtimes as JS JIT is extraordinarily good these days).

[wrs]

Not really in the case of TypeScript, because (with very small exceptions) when you “compile” TypeScript you are literally just removing the TypeScript, leaving plain JavaScript. It’s just type annotations; it doesn’t describe any runtime behavior at all.

[zamadatix]

That depends on both the target and the typescript features you use. In many cases, even when down leveling isn't involved, transpiled code can result in more than just stripping type info (particularly common in classes or things with helper functions). There's also nothing stopping a typescript compiler from optimizing transpiled (or directly compiled) code like any other compiler would, though the default typescript tools don't really go after any of that (or even produce a minified version itself using the additional type hints).

[goatlover]

But the end result is still a JS runtime.

[zamadatix]

Agreed, at least usually right now (it doesn't have to be forever, which would probably be the most realistic way for TypeScript to make meaningful runtime gains). That does not preclude the possibility of producing more optimal JavaScript code for the runtime to consume. I give a couple examples of that in the other comments.

[surajrmal]

Tell that to the deno project.

[hombre_fatal]

Deno compiles TS to JS before execution.

[darknavi]

That could be a little confusing but (generally today) TypeScript does not "run", JavaScript does.

[9rx]

> TypeScript does not "run"

Except in the case of Doom, which can run on anything.

[rs186]

This seems pedantic. As a TypeScript user who is aware of the conversations about build performance, the title is not ambiguous at all. I know exactly they are talking about build time.

[lordofgibbons]

It was ambiguous to me. When someone says making a language X-times faster, it's natural to think about runtime performance, not compile times. I know TS runs on JS runtimes, but I assumed, based on the title, they created/modified a JS runtime to natively run TS fast.

[dimitropoulos]

look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit? I know what you're getting at but the blogpost itself doesn't imply that JavaScript is 10x faster. I could complain, about your suggested change, that it's really `build and typecheck` time. It's a title. Sometimes they don't have _all_ the context. That's ok.

[pseudopersonal]

It is for me. If someone says TypeScript is faster than X, they rarely mean the build time. I understand other people's points about TypeScript not being a runtime at all and only being a compiler, but when casually saying "TypeScript is faster than say ruby", people do not mean the compiler.

[johnfn]

But no one actually says "TypeScript is faster than say ruby". They probably say "node is faster than say ruby" or maybe "bun is faster than say ruby". Perhaps they say "JavaScript is faster than say ruby", although even that is underspecified.

[Tadpole9181]

Then read the article? I don't get it - Typescript, to anyone familiar, is not a language runtime. It does not optimize. It is a transpiler. If you don't even know this much about Typescript, you aren't the audience and lack prerequisite knowledge. Go read anything on the topic.

If someone posted an article talking about the "handedness" of DNA or something, I wouldn't complain "oh, you confused me, I thought you were saying DNA has hands!"

[dimitropoulos]

well, thanks for explaining. we might just simply disagree here. when I hear "TypeScript" I think of TypeScript, and when I hear "JavaScript" I think of JavaScript. I know what you mean re: casually speaking, but this is a blogpost from the TypeScript team. That context is there, too. I think if the same title were from an AWS release note, I'd totally see what you mean.

[wrs]

Typescript is JavaScript at runtime. It’s not a separate language, just like Python with type annotations (TypePython?) is just Python at runtime. Both are just type annotations that get stripped away before anything tries to run the code. That’s the genius of the idea and why it’s so easily adopted.

[Tadpole9181]

It is quite literally a separate language. Python's type hints are a part of the Python specification and all valid Python type hints will run in any compliant Python runtime. Typescript is not, in any way, valid JavaScript. The moment you add any type syntax, you can no longer run the code in Node or Browsers without enabling a special preprocess step.

[hansifer]

Do you think JSX is a separate language?

[pnw_throwaway]

That’d be the autism kicking in, you’re gonna have to be 10% less miserable if you want anyone to put up with you.

[legohead]

misleading titles are a no-no on HN.

I agree with pseudopersonal in that the title should be changed. technically it's not misleading, but not everyone uses or is familiar with typescript.

[k__]

It could have been a new TSC that compiles to WASM.

[jasonjmcghee]

Unfortunately many people only look at headlines, so titles do matter. People take them at face value.

[dimitropoulos]

yes, and TypeScript is not JavaScript. Objectively, every element of _TypeScript_, strictly speaking, is well known to be separate.

[dcre]

The explanations are of course correct, but I think you're right and there's not much downside to being clearer in the title. Maybe they decided against saying "compiler" because the performance boost also covers the language server.

[hinkley]

Also it’s 4 times faster but runs multithreaded, which was tricky to do in JavaScript (but easier now).

[hot_gril]

So I'm +inf as fast using JS

[_ink_]

Does Deno benefit from that?

[TechSquidTV]

Since you don't execute TypeScript, and TS never has anything to do with the end resulting app, I don't think it was misleading at all.