14 ms·
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
by pseudopersonal 2y ago
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 2y agoTo 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).
- seanmcdirmid 2y ago> 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.
- pseudopersonal 2y agoThanks 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/nodejs-vs-deno-vs-bun/ https://betterstack.com/community/guides/scaling-nodejs/node....
- internetter 2y ago> 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 2y agoIt 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.
- fastball 2y agoThose 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).
- zem 2y agoif 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 2y agoThere are plenty of other reasons to consider TypeScript, but again, what code execution are referring to? The V8 JavaScript engine?
- zem 2y agothat'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.
- Izkata 2y ago
- jilles 2y agoIf you have to explain why something is not ambiguous it is by definition ambiguous.
- hoten 2y agoMaybe they aren't the audience. I don't see how this is ambiguous to anyone that actually uses typescript
- 01HNNWZ0MV43FF 2y agoIt 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 2y agodeno runs typescript and it won't run 10x faster. It is ambiguous.
- dwaltrip 2y agoIt seems Deno compiles typescript to JS just like everyone else. https://docs.deno.com/runtime/fundamentals/typescript/ https://docs.deno.com/runtime/fundamentals/typescript/
- totallykvothe 2y agoNo. Ambiguous means that a statement has many possible meanings, not simply that something might be confusing.
- jzackpete 2y agothat would imply the existence of an objective authority on the meaning of the statement, which is debatable
- refulgentis 2y agoI'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
- pzo 2y agothere 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.
- dec0dedab0de 2y ago“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 2y ago> “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-Design-Goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-8.html#the---erasablesyntaxonly-option https://www.typescriptlang.org/docs/handbook/release-notes/t...
- jessekv 2y ago> 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 2y agoBut 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.
- maxloh 2y ago> 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 2y agoAssemblyScript is a very limited subset of the language though.
- pas 2y agoI use TS a lot and still assumed they are embarking on a native runtime/compiler whatever epic journey.
- deleted 2y ago[deleted]
- xanth 2y agoUnfortunately many TS users have a surface level understanding of TS leading them to believe that TS is "real"
- gr__or 2y agoI can think of a DOOM that WILL run faster… https://youtu.be/0mCsluv5FXA https://youtu.be/0mCsluv5FXA
- pseudopersonal 2y agoAh thanks! I didn't realize there was a Doom running on the TS type system. I stand corrected
- nonethewiser 2y agoThat is a really funny coincidence. Of all the examples you could have picked...
- chamomeal 2y agolol 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!!
- dimitropoulos 2y agolook, 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 2y agoIt 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.
- dimitropoulos 2y agowell, 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 2y agoTypescript 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 2y agoIt 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.
- deleted 2y ago[deleted]
- fabian2k 2y agoI 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 2y agoWhen 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.
- darknavi 2y agoThat could be a little confusing but (generally today) TypeScript does not "run", JavaScript does.
- 9rx 2y ago> TypeScript does not "run" Except in the case of Doom, which can run on anything.
- Etheryte 2y agoI 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.
- zamadatix 2y agoYou 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 2y agoThe 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 2y agoTranspiling 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).
- dcre 2y agoThe 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.
- TechSquidTV 2y agoSince 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.
- ggus 2y agoAgree. TypeScript is primarily a programming language. Did they make the language faster? No. Hence, the title is misleading.
- mmcnl 2y agoFor 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 2y agoAnd 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 2y agoWhy 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?
- hansifer 2y agoThat'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?
- rs186 2y agoThis 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 2y agoIt 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.
- hot_gril 2y agoSo I'm +inf as fast using JS
- _ink_ 2y agoDoes Deno benefit from that?
- deleted 2y ago[deleted]
- hinkley 2y agoAlso it’s 4 times faster but runs multithreaded, which was tricky to do in JavaScript (but easier now).