Is there any status tracker to see what is supported and what is not, or in other words how do I know if bun supports a particular framework or a library?
Oven: The Company Behind Bun
81–90 of 122 posts
Re: Oven: The Company Behind Bun
#82I love these funny names. First time I introduced HomeBrew to my gf, she was all laughing at the funny terms: keg - Program binaries created from source bottle - Program binaries downloaded cellar - Directory where kegs / binaries are stored tap - git repository cask - macos native binary (not used in Linux)
Re: Oven: The Company Behind Bun
#83Earlier quoted context omitted.
I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.
the entire language is partially implemented yet you are judging it as if it is complete and set in stone. Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.
In practice, Rust seems to be much safer. I've seen Jarred talking about segfaults in Bun. Those are practically unheard of in Rust programs, and indicative of the possibility of quite serious security vulnerabilities.
Re: Oven: The Company Behind Bun
#84Congrats 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 fre…
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?
Re: Oven: The Company Behind Bun
#85Congrats 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 fre…
I’ve had it proven true only two times so far. First time was with esbuild.
Re: Oven: The Company Behind Bun
#86It's an incredible achievement, though I worry about the use of an unproven language (Zig) that lacks memory safety by design. JavaScript runtimes, especially those with JITs, have been plagued by vulnerabilities from memory safety, type confusion, and data races. Node.js, despite being based on V8, is still susceptible independently of V8 and introduces its own vulnerabilities. It's not sufficient for the runtime to…
Worth clarifying that Bun isn't a from-scratch JS runtime, it's a wrapper around JavaScriptCore (WebKit's JS engine), like Node is around V8 As you say, there's still plenty of room for vulnerabilities in the parts it does implement, and Zig isn't strictly memory-safe. However, Zig has lots of modern features like optional-types that help quite a bit with avoiding memory errors: https://www.scattered-thoughts.net/wri…
Does this mean you could potentially run some Node code on iOS?
Re: Oven: The Company Behind Bun
#87Why do they call it oven when you of in the cold food of out hot eat the food?
Re: Oven: The Company Behind Bun
#88It's an incredible achievement, though I worry about the use of an unproven language (Zig) that lacks memory safety by design. JavaScript runtimes, especially those with JITs, have been plagued by vulnerabilities from memory safety, type confusion, and data races. Node.js, despite being based on V8, is still susceptible independently of V8 and introduces its own vulnerabilities. It's not sufficient for the runtime to…
Re: Oven: The Company Behind Bun
#89My moneys on Just-JS. It’s consistently in the top 5 fastest web framework (beating out Rust, etc). Just-JS is already faster than Bun. Additionally, JSCore appears to be a significant reason why Bun is faster than NodeJS (V8). Just-JS is investigating switching to JSCore as well - which will only extend its lead. https://github.com/just-js/just https://www.techempower.com/benchmarks/#section=data-r21 https://twitter…
I’m thinking of building a zero-dependency toolkit on top of it. I rewrote Tailwind this weekend with that in mind, and my 4-second Tailwind build (on a 90k line project) now takes 200ms. That’s mostly due to how I architected my Tailwind library; not Bun, but Bun is fast where it’s been optimized.
I love the idea of a zero (or very low) dependency, modern toolkit. I’m rooting for Bun.
Re: Oven: The Company Behind Bun
#90Wow! That is an ambitious timeline. Also ambitious is this:
> The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible.
That’s a lot of work in a crowded space. Maybe they’re aiming for an acquisition or something?
Anyway, I wish them luck. Bun probably tops the list of projects I’m excited about at the moment.