It really seems impressive to me. I think I'll try it as a tool first, later as a runtime. Just wondering why has been built using Apple's WebKit engine vs V8, other then what they say on the blog which is just shallow infos. Anyone has a link to share or any better explanation?
Both engines are really fast, both of them have places where they beat the other. For a while, JavaScriptCore was the fastest Javascript runtime, then V8 took over again, and now Spidermonkey is the fastest if you cherry pick the right tests.
The places where WebKit lags behind aren't the places Bun really cares about. I'm honestly quite glad they add some diversity to Javascript land.
I recall reading a comment that JavaScriptCore was chosen because of performance. I believe JSC is quicker to start up, and I wouldn't be surprised if it wasn't faster at executing the type of code Bun executes as well.
I would be interested to learn from somebody with experience using both Bun and Deno: which one is actually the more compelling Node successor? Bun's website makes some impressive performance claims over Deno. Are these true in practice? And if so, why? Seems like Deno also has similar goals. Also, are there large philosophical differences between the two projects? Like Bun tries to reimplement the kitchen sink but Deno wants a new post-Node way of doing things? (Just guessing, no idea if that's true.)
Deno wanted a post-Node way but they have gone back on their original ambitions (which never resonated with me, to be frank) and now have a pretty limited compatbility whereas Bun has full compatibility with Node.
Per their own docs, Bun is not fully Node compatible [0]. In my experience, even for APIs its docs claim full-compatibility has some sharp edges. That said, Bun's node-compat story is better than Deno's.
While Node's performance story keeps improving release over release [1].
Deno wanted to be different but never did enough to force its way. Maybe if they had 10x the funding to rewrite the ecosystem. Now it's in limbo.
Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
There's plenty to consider if you don't care about Node compatibility. From what I've read (including in this thread and on the Bun PR page), Node seems pretty messy, with modules coming from different sources in different ways. In Deno you just import with a URL.
I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!
Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in support for Typescript, JSX with some tooling like linter. It's also based on V8. My best guess it's what Ryan Dahl wanted Node to be as an afterthought. Bun, technically speaking is based on Webkit, but can't really say why, seems a better all-in-on tool(also remember rome?) and not only a runtime. Also with compatibility with current frameworks out of box, Deno wasn't npm compatible some time ago and I wonder if it ever meant to be and not a pivotal change on the run
For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all.
The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
> technically speaking is based on Webkit, but can't really say why
Why Bun uses WebKit/JSC was described here:
> One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that.
These tools are way too young for anyone to have actually spent a lot of time using them.
Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem.
Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support.
So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
We're a full-stack TypeScript shop, and I manage ~50 internal libs and ~500K LOC of TS. Last month I tested out both Deno and Bun as alternative runtimes for us. TLDR: for any semi-complex codebase we have, Bun almost always works, Deno almost never works. We now run all our tests in both Node.js and Bun, and gave up on trying to make Deno happen.
1. Missing `node:http2`
2. Missing `node:test`, so it's more difficult to execute the same test files within Bun as we do via Node. I wrote a custom Bun loader to mock parts of `node:test`.
3. Vite and ESLint do not work.
4. Still occasionally segfaults, and it's difficult to find out why/where.
5. Surprisingly, some code runs slower in Bun than in Node. For example, generating JWE with symmetric encryption. But this might be WebCrypto vs OpenSSL.
6. Subtle differences between WebKit and V8 (e.g., how they handle dates).
I am annoyed with the bombastic claims behind bun.
I wasted a day trying to get vite to work when they first announced it. Really excited about not needing >1gb of ram to compile a react project... Boggles my mind that react bundling uses more RAM than compiling linux.
It is still unable compile http://chatcraft.org due to some problem with wasm plugin.
They also said that bunx --bun option was a pre-1.0 workaround, and didn't keep that promise.
Performance-wise their claims are suspect, safari js engine was always better at startup and memory use at the expense of a relatively weak JIT. They paired that up with a ton of stuff reimplemented in native code to make their cli and hello world workflows fast. This means people will be in for a perf surprise when they start bottlenecking in JS hotpaths.
And you're right to be skeptical. With performance, so much depends on your actual code and program-specific bottlenecks. The difference in runtime speed between JSC and V8 is minimal, so a lot of Bun optimization must be in the gaps between your code and the core JS engine or in startup time (e.g., running `bun install` or `bun test`).
In my benchmarks, our actual runtime performance of long-running JS code is ~25% faster under Bun than under Node. However, sometimes Bun is ~25% slower - notably with tasks that require binary processing (e.g, fflate, sharp) or encryption (e.g., jose). We're committed to JS and will be constrained by its performance for a long time, so a "free" 10-30% speed up at runtime is worth the effort, but it's not a 10x slam dunk like the benchmarks on Bun's homepage imply.
The "semi-complex" code is legacy code, aka revenue code. Started with plain JS in CJS on Node 12 and evolved to strict TS/ESM on Node 20. A lot of cruft built up from that multi-year evolution.
These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
Thanks for the reply! I'm just writing TS code that utilizes Deno/Oak and their MySQL support, to present a REST-style API. I don't know enough to say whether these depart from the standards you're recommending. If they do, I don't know how I would do routing and API support using only the things you mentioned. I'm a one-man band writing both a mobile app and the server to support it. I also know very little about scaling, which I anticipate hiring outside expertise on.
I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!
I have the luxury of toying with tech because the business around it is relatively successful. Engineering deep-dives are a lagging indicator of success (your own or your employer's) and almost never a leading one. All those "we did X/Y/Z with cutting-edge stuff" blog posts are overwhelmingly written by people who don't need to worry about bringing in money to pay for the time spent on that stuff.
Choose the tech stack that allows you to rapidly experiment in building something other people will give you money to use. That means choosing DX and iteration speed over runtime speed. That means using whatever gives you the most joy, so you're incentivized to build more often. That means something high-level so you don't waste time re-building components your customers don't care about, so you spend fewer hours on invisible, undifferentiated, but complex and time-consuming stuff.
If you're most effective with JS, Node is fine. Bun is fine. Deno is fine (for greenfield). One is super stable, battle-tested, and has 10x more contributors and 100x more libraries than the other two (most of them are trash). This maturity gap may not matter at all or may break your startup if you must re-implement something complex or continuously spend hours understanding and battling your runtime with minimal information on the web from others who encountered the same problem before. The same goes for your prod infrastructure, mobile app architecture, business ops, infosec, etc. Choose boring technology https://boringtechnology.club
Thanks for that. I'm in the middle situation, in that I'm somewhat in a hurry but not desperate (yet). So far I've been pretty encouraged by how quickly I've gotten something working with Deno; the main reason I went with it over PHP 8 is that I wanted to learn JS/TS. Second, the author's goals of addressing Node shortcomings and providing a cleaner import mechanism resonated with me. Thus far it hasn't annoyed me, which is a miracle because I'm easily annoyed. I think sifting through a vast collection of libraries (mostly junk, as you say) would annoy the shit out of me but more importantly waste valuable time.
I learned that problems that seem simple and solved apparently often aren't, regardless of how many blog posts and HN posts there are about the framework of the week. I needed to define an API, so I did so using OpenAPI. While the idea and standard seems mostly sound, the tooling (from editing to code generation) is absolute trash. I wasted soooo much time trying to make it work. Should I ever use it again, I'm writing my own tools. But right now I do just need to get stuff done.
I’m not over the moon with it but I’m kind of interested to know why I need a Node successor at all. Both Bun and Deno are VC funded tools so I have base level suspicion around monetization and longevity.
It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues.
Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility.
Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
That kind of speaks to my point, though: a number of the features listed there (e.g. test runner, .env file support, watch mode) have either been recently added to Node or will be soon (and are available today as experimental flags).
The bundler stuff is certainly more compelling though the page doesn't specify what makes it better than esbuild except that it comes built-in... but that's where, for me, VC concerns raise their head. If I go all in on Bun bundler, what happens if the company switches their priority towards monetization and neglects the bundler? I'm going to have to unroll all the configuration work I will have done and go back to an external bundling library. And it's still not entirely clear what I gain!
If it delivers on the promise of solving the require vs import module nonsense that would be enough for me. Maybe node copies that too, but that's also a win imo.
Seems they both have similar plans: serverless hosting, continuous integration, etc. etc.
All valid ideas. But the involvement of VCs makes me wonder what kind of scale they're going to be expected to achieve and what will happen if they don't.
I'm super skeptical of the viability, much less the desirability, of language VM specific CI and hosting services..
Feels like an acquisition by Cloudflare/Vercel is a more likely exit scenario.. But then if we get an HHVM repeat and most of the benefits are just introduced into Node proper what's the real value to the aquirer? Aqui-hire? Deno has raised at least $25m though, and bun $7m..
I guess most startups fail so maybe there is just no answer.
HipHop Virtual Machine was created over a decade ago to address serious performance issues with PHP. This spurred(lit a fire?) serious efforts to address the issues in PHP proper. Over a rather short period of time PHP became performant enough that HHVM was sunsetted.
I think the history here would call into question the viability of Bun as a monetary investment. It may end up a net good for the ecosystem , but if the major benefits can just be incorporated back into Node proper what are the ROI prospects?
I thought you're original comment was saying something to the effect of "VCs funded HHVM, and this feels similar."
I'd only heard of HHVM in the context of Facebook, so I was surprised to read that (but I know Phabricator was another infrastructure company spun out of FB, so it seemed possible).
If you don't trust bun.sh don't do it. They would be torpedoing their project if they put something nefarious in there though, and it would probably more effective to put the nefarious stuff in bun directly. Yes a 3rd party could have gained access to their site and modified that script, but that's covered under "trust bun.sh".
If you can't trust that, then I suppose you're checking every node_modules dir for any malicious codes but I guess you're just being allergic to pipe bash.
I don't like `curl|bash` not because it's insecure but because I don't know what it's doing to my system, and I don't believe that it understands my system properly. Ideally I'd download a single binary and put it in /usr/local/bin myself.
Slightly hijacking this thread to ask: I've not heard of Platform.sh before. Do y'all have a free/hobby plan for someone wanting to become familiar with the it? If not, no worries.
We are not big on free. We like money :) And people like that we will probably be around in a decade (and won't stop free as soon as we've locked enough people -in). We do have a no-strings-attached free trial ...
"Unlike Node.js and other runtimes that are built using Google's V8 engine, Bun is built using Apple's WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It's fast, efficient, and has been battle-tested for decades."
That's really interesting, does WebKit do less JITing or something to be faster for startup?
bun startup is fast compared to other JS runtimes but imo this is little or nothing to do with JSC versus v8 as the javascript engine. i did some experiments a while back and wrote them up here if you want to take a look.
https://just.billywhizz.io/blog/on-javascript-performance-03...
If Bun is able to run and bundle a TypeScript React app out-of-the-box, what are the benefits of using Vite.js on top of it?
I'm confused cause this guide on the official site showcases how to use Bun + Vite.js to build a TypeScript React app. [1]
There is also this issue on their Github. [2]
Can Vite.js be used to handle more complicated scenarios / advanced use cases that Bun doesn't handle? My use of Vite.js is pretty basic (start & build with the default TS+React config) so maybe I'm missing something here.
Vite still leverages node, esbuild, swc, tsc, etc for parts it’s not directly responsible for.
Granted I have no experience with bun yet, my take on it is that you can leverage bun for running the local dev server (instead of node), leverage bun for bundling (instead of esbuild or tsc or rollup or an amalgamation of them), and leverage bun for transpiring instead of Babel and typescript.
What vite provides is an easy to configure setup for developing frontend applications with a nice DevX when working locally.
that's like asking why need vite when you have tsc. I assume bun does not "run Typescript React app", it only does the jsx,tsx transpiling out of the box.
It's a big ask to get people to adopt an ecosystem wholesale. Compatibility with the existing ecosystem is a key goal of Bun, so that people can start using it immediately on their existing codebases and then adopt it gradually for more and more stuff
Personal experience: Bun has been a flawless drop-in replacement for both NodeJS and npm/yarn since I started using it around v0.4. Not only have I had zero issues running it, but it's been WAY faster. No benchmarks, but very noticeable, from "let's start a new build and go grab a coffee while waiting for it" on NodeJS, to "hit run aaaaand it's done."
I haven't thought twice about it. Frankly, I forgot that bun has been happily running behind the scenes for me. I highly recommend anyone using NodeJS to give it a go.
I've worked on several large node.js codebases and builds never took more than a few seconds, def. not "go grab coffee" time, so maybe something else was going on.
> It reads your package.json and writes to node_modules, just like other package managers, so you can replace:
> ...
> pnpm
pnpm's flagship feature is global deduplication of packages, so sadly bun's package manager doesn't seem to be a replacement. Is there any plan or intention to support pnpm-like disk saving? (I suppose not having to esbuild etc. everywhere already helps.)
That said, I'm very impressed with the speed of `bun add` with already cached packages. Literally instant.
Nice! I was looking at du(1) output on macOS which appears to indicate all files are duplicated. It probably just can’t tell the files are clonefile’d.
There is a very obscure undocumented api in macOS for detecting if two files are equal block-by-block but yeah I don’t think most tools can tell when files are clonefile’d
Just a note on your documentation: it says "this benefit does not extend to macOS" about saving disk space. I find that to be slightly misleading. Since arguably the most common FS for macOS is now APFS, it does save significant disk space unless one were to modify the node_modules files.
You're jumping to conclusions: I just tried the package.json below, and bun's node_modules folder is smaller than pnpm's (3.9M with pnpm vs 3.4M with bun), and as a sibling noted, bun is also deduplicating globally.
That, coupled with the fact that bun installs twice as fast when no packages are cached (634ms compared to 1.3s) and 100x as fast when all packages are cached (6ms to 639ms), I think it's fair to say that bun can replace pnpm.
Congratulation to the project, it seems incredible.
I don't know that much so I have some questions, sorry if they're already answered. (share link if any if its possible)
Do you plan to support as much as possible the Node.js API (99%) or most features and make your own API for lets say Clustering module and such ?
Speaking of Cluster module, do you want to recreate Node.js Cluster module, or do you plan to create your own way for multi-processing using Bun in a more performant way ?
I've seen Deno putting a lot of effort into the platform around their runtime, making deploying Deno app easy, is that your goal too ?
I've seen that you use Zig instead of C++, what do you like the most about Zig while working on Bun ?
In anyway, I hope the project will make the JSRuntime world better, its promising.
You write typescript and unit test without tsc, jest, webpack/esbuild or a ton of config files. bun projects can be super lean and still cough out a tested bundle.js for execution on a browser.
I love it, it super simplifies project and for minimalists it's perfect.
How do you do type-checking? Do you just run TSC with “noEmit: true”, like you’d do with any other bundler?
TSC is simultaneously the most valuable and the most flaky part of your typical JS project setup. That’s the main part I’d be interested in replacing with a different tool.
It reads the tsconfig file if present. You just write TS files and bun build outputs JS. Vscode highlights typecheck errors based on TS errors. Bun build fails if you can't typecheck. No tsc installation necessary, but also consistency with tsc if you use a tsconfig. For simple stuff tsconfig is not needed
I am mistaken. Yeah bun does not typescheck like esbuild doesn't. It reads the tsconfig for build options. Either you add tsc or let your editor do it.
Bun ships features and improvements fast and often, which is great
But from anecdotes, I have the impression people still run into bugs and missing functionality semi-commonly. I'm sure it works great for small/personal projects, but I've been hesitant to recommend it for production use at my workplace because of this impression
So my question is: how feature-complete/stable/secure is it right now, what does the v1.0 label say about that, and what are the long-term plans/prioritization/guarantees around this area?
371 comments
[ 2.3 ms ] story [ 305 ms ] threadThe places where WebKit lags behind aren't the places Bun really cares about. I'm honestly quite glad they add some diversity to Javascript land.
I recall reading a comment that JavaScriptCore was chosen because of performance. I believe JSC is quicker to start up, and I wouldn't be surprised if it wasn't faster at executing the type of code Bun executes as well.
Any seasoned users with time spent on both?
While Node's performance story keeps improving release over release [1].
[0] https://archive.is/NCzRQ
[1] https://twitter.com/lemire/status/1699459534190698999
Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!
For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all.
The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
I say now, anyway!
Why Bun uses WebKit/JSC was described here:
> One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that.
via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...
But, the command `bun install` supports NPM and custom registries, as well as Git and .tgz URLs.
https://bun.sh/docs/cli/install#git-dependencies
Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem.
Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support.
So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
I did raise issues with repros for it only wasn't able to try to fix the issues myself. Building Bun is not working for me
I wasted a day trying to get vite to work when they first announced it. Really excited about not needing >1gb of ram to compile a react project... Boggles my mind that react bundling uses more RAM than compiling linux.
It is still unable compile http://chatcraft.org due to some problem with wasm plugin.
They also said that bunx --bun option was a pre-1.0 workaround, and didn't keep that promise.
Performance-wise their claims are suspect, safari js engine was always better at startup and memory use at the expense of a relatively weak JIT. They paired that up with a ton of stuff reimplemented in native code to make their cli and hello world workflows fast. This means people will be in for a perf surprise when they start bottlenecking in JS hotpaths.
In my benchmarks, our actual runtime performance of long-running JS code is ~25% faster under Bun than under Node. However, sometimes Bun is ~25% slower - notably with tasks that require binary processing (e.g, fflate, sharp) or encryption (e.g., jose). We're committed to JS and will be constrained by its performance for a long time, so a "free" 10-30% speed up at runtime is worth the effort, but it's not a 10x slam dunk like the benchmarks on Bun's homepage imply.
I have never used Node and am creating a new project from scratch, so I don't know how worried to be about your commentary.
These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!
Choose the tech stack that allows you to rapidly experiment in building something other people will give you money to use. That means choosing DX and iteration speed over runtime speed. That means using whatever gives you the most joy, so you're incentivized to build more often. That means something high-level so you don't waste time re-building components your customers don't care about, so you spend fewer hours on invisible, undifferentiated, but complex and time-consuming stuff.
If you're most effective with JS, Node is fine. Bun is fine. Deno is fine (for greenfield). One is super stable, battle-tested, and has 10x more contributors and 100x more libraries than the other two (most of them are trash). This maturity gap may not matter at all or may break your startup if you must re-implement something complex or continuously spend hours understanding and battling your runtime with minimal information on the web from others who encountered the same problem before. The same goes for your prod infrastructure, mobile app architecture, business ops, infosec, etc. Choose boring technology https://boringtechnology.club
I learned that problems that seem simple and solved apparently often aren't, regardless of how many blog posts and HN posts there are about the framework of the week. I needed to define an API, so I did so using OpenAPI. While the idea and standard seems mostly sound, the tooling (from editing to code generation) is absolute trash. I wasted soooo much time trying to make it work. Should I ever use it again, I'm writing my own tools. But right now I do just need to get stuff done.
It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues.
Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility.
Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
This is extremely compelling for frontend DX.
The bundler stuff is certainly more compelling though the page doesn't specify what makes it better than esbuild except that it comes built-in... but that's where, for me, VC concerns raise their head. If I go all in on Bun bundler, what happens if the company switches their priority towards monetization and neglects the bundler? I'm going to have to unroll all the configuration work I will have done and go back to an external bundling library. And it's still not entirely clear what I gain!
Not sure how they plan on monetizing.
All valid ideas. But the involvement of VCs makes me wonder what kind of scale they're going to be expected to achieve and what will happen if they don't.
Feels like an acquisition by Cloudflare/Vercel is a more likely exit scenario.. But then if we get an HHVM repeat and most of the benefits are just introduced into Node proper what's the real value to the aquirer? Aqui-hire? Deno has raised at least $25m though, and bun $7m..
I guess most startups fail so maybe there is just no answer.
HipHop Virtual Machine was created over a decade ago to address serious performance issues with PHP. This spurred(lit a fire?) serious efforts to address the issues in PHP proper. Over a rather short period of time PHP became performant enough that HHVM was sunsetted.
I think the history here would call into question the viability of Bun as a monetary investment. It may end up a net good for the ecosystem , but if the major benefits can just be incorporated back into Node proper what are the ROI prospects?
I thought you're original comment was saying something to the effect of "VCs funded HHVM, and this feels similar."
I'd only heard of HHVM in the context of Facebook, so I was surprised to read that (but I know Phabricator was another infrastructure company spun out of FB, so it seemed possible).
Edit: sounds like this is changing. Thanks for the correction!
Could the mods change the link to the blog post? It explains better than the github release page
Blog post: https://bun.sh/blog/bun-v1.0
what type of project can I use Bun on without regretting it (due to unforeseen bugs, incompatibilities, etc)?
"Unlike Node.js and other runtimes that are built using Google's V8 engine, Bun is built using Apple's WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It's fast, efficient, and has been battle-tested for decades."
That's really interesting, does WebKit do less JITing or something to be faster for startup?
I am still absolutely amazed at how much more performant websockets throughput in bun vs node.
Congrats on 1.0!
I'm confused cause this guide on the official site showcases how to use Bun + Vite.js to build a TypeScript React app. [1]
There is also this issue on their Github. [2]
Can Vite.js be used to handle more complicated scenarios / advanced use cases that Bun doesn't handle? My use of Vite.js is pretty basic (start & build with the default TS+React config) so maybe I'm missing something here.
--
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
Granted I have no experience with bun yet, my take on it is that you can leverage bun for running the local dev server (instead of node), leverage bun for bundling (instead of esbuild or tsc or rollup or an amalgamation of them), and leverage bun for transpiring instead of Babel and typescript.
What vite provides is an easy to configure setup for developing frontend applications with a nice DevX when working locally.
And most of the new meta frameworks(nuxt,sveltekit,astro,solidstart,qwik) runs on vite so that might pave a path for adoption.
I haven't thought twice about it. Frankly, I forgot that bun has been happily running behind the scenes for me. I highly recommend anyone using NodeJS to give it a go.
And Bun is going to improve that?
> ...
> pnpm
pnpm's flagship feature is global deduplication of packages, so sadly bun's package manager doesn't seem to be a replacement. Is there any plan or intention to support pnpm-like disk saving? (I suppose not having to esbuild etc. everywhere already helps.)
That said, I'm very impressed with the speed of `bun add` with already cached packages. Literally instant.
[0] https://bun.sh/docs/install/cache#saving-disk-space
According to that, the speed benefits will probably not be as noticeable in windows.
That, coupled with the fact that bun installs twice as fast when no packages are cached (634ms compared to 1.3s) and 100x as fast when all packages are cached (6ms to 639ms), I think it's fair to say that bun can replace pnpm.
Here's the package.json I tried:
I know it’s possible to get it to work, but I didn’t have time to fiddle all the bits.
If Bun made this easier, I’d switch from pnpm immediately.
[0]: https://bun.sh/guides/ecosystem/nextjs
I don't know that much so I have some questions, sorry if they're already answered. (share link if any if its possible)
Do you plan to support as much as possible the Node.js API (99%) or most features and make your own API for lets say Clustering module and such ?
Speaking of Cluster module, do you want to recreate Node.js Cluster module, or do you plan to create your own way for multi-processing using Bun in a more performant way ?
I've seen Deno putting a lot of effort into the platform around their runtime, making deploying Deno app easy, is that your goal too ?
I've seen that you use Zig instead of C++, what do you like the most about Zig while working on Bun ?
In anyway, I hope the project will make the JSRuntime world better, its promising.
I love it, it super simplifies project and for minimalists it's perfect.
TSC is simultaneously the most valuable and the most flaky part of your typical JS project setup. That’s the main part I’d be interested in replacing with a different tool.
It has to run TSC (or expect somebody else to run it) in order to typecheck, though, right?
> Bun can run .js, .ts, .cjs, .mjs, .jsx, and .tsx files, which can replace: > > tsc — (but you can keep it for typechecking!)
But from anecdotes, I have the impression people still run into bugs and missing functionality semi-commonly. I'm sure it works great for small/personal projects, but I've been hesitant to recommend it for production use at my workplace because of this impression
So my question is: how feature-complete/stable/secure is it right now, what does the v1.0 label say about that, and what are the long-term plans/prioritization/guarantees around this area?