First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.
Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.
Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.
Saying there’s no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you’re effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.
Perhaps bun would be even faster if they bound against another JS API, but that doesn’t mean that Bun isn’t faster than Node.js. They claim it’s 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.
I’m not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn’t faster than Node in aggregate, I don’t think the claim can be called “wrong” on its face.
E: that’s exactly what Bun does: “Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it.”
https://bun.com/
HTML title: Bun: A fast all-in-one JavaScript runtime
https://bun.com/docs/runtime
Am I missing something? How is that claim incorrect? I’ve never used Bun but their marketing material lines up exactly with the claim.
First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.
Second of all, bun binds against
JavaScriptCore, which is the JS engine used in Safari. Node binds againstV8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.
Saying there’s no typescript runtime is (imo) a bit pedantic - if you JIT transpile TS down to JS at run time with hot-reloading you’re effectively a TS runtime. For a non-technical one-liner on Bun, I feel that is a very reasonable simplification to make.
Perhaps bun would be even faster if they bound against another JS API, but that doesn’t mean that Bun isn’t faster than Node.js. They claim it’s 3x faster than Node in aggregate, and that can potentially be true even if they use slower machinery under the hood. Python is a slow language but a fast framework can outperform a poorly written C++ implementation.
I’m not going to defend the article, I have no horse in that race, but until I see benchmarks that say Bun isn’t faster than Node in aggregate, I don’t think the claim can be called “wrong” on its face.
E: that’s exactly what Bun does: “Bun supports TypeScript and JSX with no configuration. Bun transpiles every file on the fly with its native transpiler before running it.”
I’m going to call
cargoa Rust runtime from now on, consideringcargo-scriptexists.Take the L and move on