5 ms·

Congrats to Jarred! Bun has blown me away in terms of performance. Often (in other projects) performance claims out of nowhere are simply cherry-picked but I’v

Congrats to Jarred! Bun has blown me away in terms of performance. Often (in other projects) performance claims out of nowhere are simply cherry-picked but I’ve found bun repeatedly impressing me with both speed and elegance. What doesn’t get mentioned enough is just how friggin ergonomic bun is. Install it and you’ll see what I mean immediately. Play with any API in the “bun:” namespace and it’s just a breath of fresh air.

verdverm 4y ago
I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking? Bun is definitely not production ready yet, but I'm keeping my eye on it for sure https://github.com/oven-sh/bun#not-implemented-yet https://github.com/oven-sh/bun#not-implemented-yet
- brrrrrm 4y ago
  I’m not familiar with deployment in the modern web world, but I’m curious how fast those specific features need to be in a production setting? Are they done dynamically for every request?
- ctvo 4y ago
  > I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking? Can you explain why you think a transpilation step will prove to be a technical challenge here? The "bundler" part of Bun seems like a very small piece, and not something that would impact its performance as a runtime too greatly.
  - brundolf 4y ago
    A lot of the conversation around Bun's performance has included the performance of non-runtime things like how fast it can install packages, perform builds, cold-start, etc
  - verdverm 4y ago
    I only use JS/TS on the client side, which will end up running in the browser, thus being able to use Bun to create production code will require these features. I didn't say they were technical challenges, but these processes require more complex analysis and algos.
- Jarred 4y ago
  Sourcemaps are technically already implemented, but not for bundled dependencies. Initially, it was a 30% drop, but I made it use lots of SIMD and that compensated a lot. When you use Bun's runtime, it transpiles every file (including non-TypeScript files) and generates an in-memory sourcemap so that error messages have useful line/column numbers. Bun's fast startup time is very much in spite of things like this. Minification will likely make it faster because there will be less code to print (see https://twitter.com/evanwallace/status/1396304029840396290 https://twitter.com/evanwallace/status/1396304029840396290). Many of the syntax compression and small optimizations like ("foo" + " " + "bar") becoming "foo bar" are implemented already, but not the whitespace removal It might have an impact on bundling performance overall because that will involve an extra pass to more correctly handle `export * as from`, which isn't as important when used with the runtime (since that can happen at runtime)
  - verdverm 4y ago
    I'm not looking to use Bun as a JS runner because all of my JS runs in the browser. The time and complexity of implementing these processes will increase build time. We will have to wait to see how it compares to existing tools for bundling and creating production code.
brundolf 4y ago
I'm curious about where all that performance comes from I know it uses the WebKit JS runtime instead of V8, which is super interesting. Does that cause a performance lift? Or is there some other secret sauce that pervades throughout Bun? Or is it just a matter of Jarred giving lots of attention to spot-optimizing the most important bottlenecks outside of the core runtime?
- brrrrrm 4y ago
  I suspect it’s the latter. I would guess V8 with a thin wrapper and a ton of effort from someone who cares about perf to port all the native goodies of node would get similar wins.
  - cheeselip420 4y ago
    Good thing Cloudflare is open-sourcing their V8-based Workers runtime soon.
    - deleted 4y ago
      [deleted]
  - ricardobeat 4y ago
    Absolutely. And it has been done already, JustJS[1] has made it to the top 10 fastest in the TechEmpower benchmarks. It’s Linux only though, and not nearly as complete or easy to use, which makes it unappealing for real world projects. [1] https://github.com/just-js/just https://github.com/just-js/just
- Jarred 4y ago
  There's no secret sauce Just lots of time spent profiling and trying things On the runtime side, JavaScriptCore/WebKit's team are extremely receptive to feedback, especially performance-related. Today, @Constellation made `Promise.all` about 30% faster https://github.com/WebKit/WebKit/pull/3569 https://github.com/WebKit/WebKit/pull/3569
  - 4y ago
Aeolun 4y ago
> Often (in other projects) performance claims out of nowhere are simply cherry-picked I’ve had it proven true only two times so far. First time was with esbuild.

verdverm 4y ago

I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking? Bun is definitely not production ready yet, but I'm keeping my eye on it for sure https://github.com/oven-sh/bun#not-implemented-yet https://github.com/oven-sh/bun#not-implemented-yet

brrrrrm 4y ago
I’m not familiar with deployment in the modern web world, but I’m curious how fast those specific features need to be in a production setting? Are they done dynamically for every request?
ctvo 4y ago
> I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking? Can you explain why you think a transpilation step will prove to be a technical challenge here? The "bundler" part of Bun seems like a very small piece, and not something that would impact its performance as a runtime too greatly.
- brundolf 4y ago
  A lot of the conversation around Bun's performance has included the performance of non-runtime things like how fast it can install packages, perform builds, cold-start, etc
- verdverm 4y ago
  I only use JS/TS on the client side, which will end up running in the browser, thus being able to use Bun to create production code will require these features. I didn't say they were technical challenges, but these processes require more complex analysis and algos.
Jarred 4y ago
Sourcemaps are technically already implemented, but not for bundled dependencies. Initially, it was a 30% drop, but I made it use lots of SIMD and that compensated a lot. When you use Bun's runtime, it transpiles every file (including non-TypeScript files) and generates an in-memory sourcemap so that error messages have useful line/column numbers. Bun's fast startup time is very much in spite of things like this. Minification will likely make it faster because there will be less code to print (see https://twitter.com/evanwallace/status/1396304029840396290 https://twitter.com/evanwallace/status/1396304029840396290). Many of the syntax compression and small optimizations like ("foo" + " " + "bar") becoming "foo bar" are implemented already, but not the whitespace removal It might have an impact on bundling performance overall because that will involve an extra pass to more correctly handle `export * as from`, which isn't as important when used with the runtime (since that can happen at runtime)
- verdverm 4y ago
  I'm not looking to use Bun as a JS runner because all of my JS runs in the browser. The time and complexity of implementing these processes will increase build time. We will have to wait to see how it compares to existing tools for bundling and creating production code.

brundolf 4y ago

I'm curious about where all that performance comes from I know it uses the WebKit JS runtime instead of V8, which is super interesting. Does that cause a performance lift? Or is there some other secret sauce that pervades throughout Bun? Or is it just a matter of Jarred giving lots of attention to spot-optimizing the most important bottlenecks outside of the core runtime?

brrrrrm 4y ago
I suspect it’s the latter. I would guess V8 with a thin wrapper and a ton of effort from someone who cares about perf to port all the native goodies of node would get similar wins.
- cheeselip420 4y ago
  Good thing Cloudflare is open-sourcing their V8-based Workers runtime soon.
  - deleted 4y ago
    [deleted]
- ricardobeat 4y ago
  Absolutely. And it has been done already, JustJS[1] has made it to the top 10 fastest in the TechEmpower benchmarks. It’s Linux only though, and not nearly as complete or easy to use, which makes it unappealing for real world projects. [1] https://github.com/just-js/just https://github.com/just-js/just
Jarred 4y ago
There's no secret sauce Just lots of time spent profiling and trying things On the runtime side, JavaScriptCore/WebKit's team are extremely receptive to feedback, especially performance-related. Today, @Constellation made `Promise.all` about 30% faster https://github.com/WebKit/WebKit/pull/3569 https://github.com/WebKit/WebKit/pull/3569
- 4y ago

Aeolun 4y ago

> Often (in other projects) performance claims out of nowhere are simply cherry-picked I’ve had it proven true only two times so far. First time was with esbuild.