6 ms·

Bun has completely changed my outlook on the JS ecosystem. Prior to Bun, there was little focus on performance. Now the entire space rallies around it. Congrat

Bun has completely changed my outlook on the JS ecosystem. Prior to Bun, there was little focus on performance. Now the entire space rallies around it. Congrats to Jarred and the team!

nailer 10mo ago
One important original point of node was that v8 made JS very fast by compiling to machine code, plus it’s had multithreading built in for a decade.
- whizzter 10mo ago
  Machine code yes (along with Spidermonkey, JSC and Nashorn), the timeframe around 2005-2010 saw the introduction of JIT'ed JS runtimes. Back then however JS was firmly single-threaded, it was only with the introduction of SharedArrayBuffer that JS really started to receive multithreading features (outside of SharedArrayBuffer and other shareable/sendable types, a runtime could opt to run stuff like WebWorkers/WebAudioWorkers in separate processes). Early Node f.ex. had a multi-process setup built in, Node initially was about pushing the async-IO model together with a fast JS runtime. Why Bun (and partially Deno) exists is because TypeScript helps so damn much once projects gets a tad larger, but usage with Node hot-reloading was kinda slow, multiple seconds from saving a file until your application reloads. Even mainline node nowadays has direct .ts file loading and type erasing to quicken the workflow.
stefan_ 10mo ago
That is the most absurd thing I've heard in 20 years. Chrome literally was launched on performance, for JS and beyond. The reality is that the insane "JS ecosystem" will rally around whatever is the latest hotness.
satvikpendem 10mo ago
That's because it's not written in JS at all but a compiled systems language, no wonder it's gonna be fast.
- denismenace 10mo ago
  Virtually all JavaScript engines are written in compiled languages. (Most runtimes for that matter nut just JS)
  - satvikpendem 10mo ago
    My mistake, I was thinking of the wider ecosystem not the runtime, ie formatters, bundles and linters like Biome, oxc, etc being written in Rust or other compiled languages. That's where I saw the biggest speedup, because developers of them decided to use a compiled language to write them in instead of JS via a JS runtime where you'll inherently be limited by even a JIT language.
krig 10mo ago
> Prior to Bun, there was little focus on performance. This is just completely insane. We went through more than a decade of performance competition in the JS VM space, and the _only_ justification that Google had for creating V8 was performance. > The V8 engine was first introduced by Google in 2008, coinciding with the launch of the Google Chrome web browser. At the time, web applications were becoming increasingly complex, and there was a growing need for a faster, more efficient JavaScript engine. Google recognized this need and set out to create an engine that could significantly improve JavaScript performance. I guess this is the time we live in. Vibe-coded projects get bought by vibe-coded companies and are congratulated in vibe-coded comments.
- logsr 10mo ago
  > Vibe-coded projects get bought by vibe-coded companies this is so far from the truth. Bun, Zig, and uWebsockets are passion projects run by individuals with deep systems programming expertise. furthest thing from vibe coding imaginable. > a decade of performance competition in the JS VM space this was a rising tide that lifted all boats, including Node, but Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves.
  - creata 10mo ago
    > Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves That sounds like an implementation difference, not an architectural difference. If they wanted to, what would prevent Node or a third party from implementing parts of the stdlib in a faster language?
    - logsr 10mo ago
      uWebsockets, which is the foundation of the network and http server stack in Bun, as I understand it, is a compatible 3rd party extension to Node.js that gives it similar performance on HTTP implementation. The key architectural difference is that Node.js implements the HTTP stack and other low level libraries in JavaScript, which gives it memory safety guarantees provided by the v8 runtime, while Bun/uWebsockets are a zig/C++ implementation. for Node.js, which is focused on enterprise adoption, the lower performance JS approach better aligns with the security profile of their enterprise adoption target.
School-Cotton 10mo ago
> Prior to Bun, there was little focus on performance v8 is one of the most advanced JIT runtimes in the world. A lot of people have spent a lot of time focusing on its performance.

Bun has completely changed my outlook on the JS ecosystem. Prior to Bun, there was little focus on performance. Now the entire space rallies around it. Congrats to Jarred and the team!

nailer 10mo ago

One important original point of node was that v8 made JS very fast by compiling to machine code, plus it’s had multithreading built in for a decade.

whizzter 10mo ago
Machine code yes (along with Spidermonkey, JSC and Nashorn), the timeframe around 2005-2010 saw the introduction of JIT'ed JS runtimes. Back then however JS was firmly single-threaded, it was only with the introduction of SharedArrayBuffer that JS really started to receive multithreading features (outside of SharedArrayBuffer and other shareable/sendable types, a runtime could opt to run stuff like WebWorkers/WebAudioWorkers in separate processes). Early Node f.ex. had a multi-process setup built in, Node initially was about pushing the async-IO model together with a fast JS runtime. Why Bun (and partially Deno) exists is because TypeScript helps so damn much once projects gets a tad larger, but usage with Node hot-reloading was kinda slow, multiple seconds from saving a file until your application reloads. Even mainline node nowadays has direct .ts file loading and type erasing to quicken the workflow.

stefan_ 10mo ago

That is the most absurd thing I've heard in 20 years. Chrome literally was launched on performance, for JS and beyond. The reality is that the insane "JS ecosystem" will rally around whatever is the latest hotness.

satvikpendem 10mo ago

That's because it's not written in JS at all but a compiled systems language, no wonder it's gonna be fast.

denismenace 10mo ago
Virtually all JavaScript engines are written in compiled languages. (Most runtimes for that matter nut just JS)
- satvikpendem 10mo ago
  My mistake, I was thinking of the wider ecosystem not the runtime, ie formatters, bundles and linters like Biome, oxc, etc being written in Rust or other compiled languages. That's where I saw the biggest speedup, because developers of them decided to use a compiled language to write them in instead of JS via a JS runtime where you'll inherently be limited by even a JIT language.

krig 10mo ago

> Prior to Bun, there was little focus on performance. This is just completely insane. We went through more than a decade of performance competition in the JS VM space, and the _only_ justification that Google had for creating V8 was performance. > The V8 engine was first introduced by Google in 2008, coinciding with the launch of the Google Chrome web browser. At the time, web applications were becoming increasingly complex, and there was a growing need for a faster, more efficient JavaScript engine. Google recognized this need and set out to create an engine that could significantly improve JavaScript performance. I guess this is the time we live in. Vibe-coded projects get bought by vibe-coded companies and are congratulated in vibe-coded comments.

logsr 10mo ago
> Vibe-coded projects get bought by vibe-coded companies this is so far from the truth. Bun, Zig, and uWebsockets are passion projects run by individuals with deep systems programming expertise. furthest thing from vibe coding imaginable. > a decade of performance competition in the JS VM space this was a rising tide that lifted all boats, including Node, but Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves.
- creata 10mo ago
  > Node is built with much more of the system implemented in JS, so it is architecturally incapable of the kind of performance Bun/uWebsockets achieves That sounds like an implementation difference, not an architectural difference. If they wanted to, what would prevent Node or a third party from implementing parts of the stdlib in a faster language?
  - logsr 10mo ago
    uWebsockets, which is the foundation of the network and http server stack in Bun, as I understand it, is a compatible 3rd party extension to Node.js that gives it similar performance on HTTP implementation. The key architectural difference is that Node.js implements the HTTP stack and other low level libraries in JavaScript, which gives it memory safety guarantees provided by the v8 runtime, while Bun/uWebsockets are a zig/C++ implementation. for Node.js, which is focused on enterprise adoption, the lower performance JS approach better aligns with the security profile of their enterprise adoption target.

School-Cotton 10mo ago

> Prior to Bun, there was little focus on performance v8 is one of the most advanced JIT runtimes in the world. A lot of people have spent a lot of time focusing on its performance.