19 ms·

Will Bun JavaScript Take Node's Crown

298 points by kiyanwang 4y ago

birdyrooster 4y ago
Node never had a crown. It’s a dirty turd.
dimitrios1 4y ago
OK now in true JS fashion, somebody make a combo of the two - Bun lacks Denos best feature which is the permission system / sandboxed by default operation - Deno lacks Bun's best feature which is backwards compatibility with NPM
matsemann 4y ago
Speed isn't really the biggest factor for most of my node usage, though. Of course, if it's a drop-in replacement one might switch. An aside, but as a non-native speaker and haven't heard of Bun before, an all-capitalized title is very confusing. "Who is Will Bun"?
- papito 4y ago
  Speed nowadays is almost an anti-goal. People choose the "fastest" language or framework, then add a bunch of lazy ORM queries without really knowing how to properly leverage a performant database, stitch together a bunch of "microservices", adding multiple HTTP trips across the wire, and by that time the performance of the core language is a rounding error.
  - makeitdouble 4y ago
    To note, nowadays node is not just for production runtime. Anything related to tooling (compilation/check/bundling etc.) for instance will benefit from faster runtimes. Also, having a slower runtime only marginally push people to code more efficiently (e.g. people wanting to use an ORM will do so either way)
  - lpapez 4y ago
    I got a PHP gig recently (after working as a Go developer for some time), and this rings very true to me. In PHP you often have to make the most of your database, and this tends to result in a far more enjoyable codebase experience.
  - nickserv 4y ago
    Sure, until you're stuck on some inner loop with a poorly performing language. Of course,if you're doing microservices correctly, it should be easy to separate the parts where performance is important and write them in a language optimized for that.
    - papito 4y ago
      That is almost never used correctly. I have not seen it, for one. If it's crazy math calculations, file processing, image processing - sure, but that's not how microservices are used in 99% of the cases. It's basically an anti-pattern.
  - crabmusket 4y ago
    Are you saying that performance can't be outsourced?
- jraph 4y ago
  Yes, I had to backtrack while parsing this sentence. Not all-capitalized would not have helped, "will" is still the first word, so would get capitalized regardless, and Bun is a proper name that would also get capitalized. It doesn't help that "bun" is a kind of bread, and is also part of the name of the "bo bun" dish. An "?" at the end would have helped a lot though.
- AlfeG 4y ago
  For me speed issue is totally solved by Vite. Moved whole project to it including old legacy scripts.
bongobingo1 4y ago
> Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. :-1: I loath to use discords search interface to look for information. I'm sure the Bun team doesn't see this as an end goal, but I wish forums were still a thing. At least they're mostly indexed.
- toastal 4y ago
  > Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority. — Matt Lee https://www.linuxjournal.com/content/opinion-github-vs-gitlab https://www.linuxjournal.com/content/opinion-github-vs-gitla...
  - nickserv 4y ago
    I agree, but nobody bats an eye if your open source project is hosted on GitHub.
    - aposm 4y ago
      I see your point, and I don't use GH when I can avoid it, but those are very different in my mind. GH, for all its flaws, is a value-added hosting service on top of git. It interoperates freely with any other Git host and you can clone/pull at any time. Discord is in an entirely different category: a completely proprietary reimplementation of IRC, with rent-seeking features bolted on.
      - emkoemko 4y ago
        IRC is horrible compared to Discord at least you have a history to of chat vs nothing.
        toastal 4y ago
        This is why SourceHut provides an IRC bouncer with its paid subscription because they are committed to the usability of IRC.
5350-uiop-1130 4y ago
another day, another javascript runtime environment
- ikt 4y ago
  as far as I'm aware Bun is significantly faster than others while maintaining a lot of the compatibility
  - thrown_22 4y ago
  - lmarcos 4y ago
    The problem of the JS ecosystem is not speed precisely.
- bigDinosaur 4y ago
  do we actually get many Javascript runtimes? Certainly fewer than JS frameworks.
  - deleted 4y ago
    [deleted]
- criley2 4y ago
  Is there really that many? Outside of browsers, I know of Node, Deno and now Bun. Is there really that many serious attempts to replace node?
  - v413 4y ago
    Bun is using the JavaScriptCore engine which is the Webkit/Safari Javascript engine. It is not written in Zig.
  - SahAssar 4y ago
    The engine (V8 analog) is not a "Zig engine", it's javascriptcore. The wrapper is Zig, like node is C/C++ and deno is Rust.
gervwyk 4y ago
Nice article. Was listening to this chat [0] recently. Jarred Sumner is doing really cool things with this! Excited to see where it goes. [0] - https://youtu.be/rL4qpniIR7o https://youtu.be/rL4qpniIR7o
- williamstein 4y ago
  That’s a great interview. He sites one of his motivations for wanting to make the dev cycle faster: “if it is slow you get distracted and read Hacker News”…
jeroenhd 4y ago
There are some real obvious downsides to using this tool right now. Most importantly, the article lists there: * Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. I'm not interested in becoming part of a community, I want to use the tool. Without official docs, I'll pass until the project has matured. * Bun is not 100% compatible with Node yet. Not every npm package works. Express, for instance, is not yet functional. I don't expect full bug-for-bug Node compatibility but if extremely popular packages such as Express don't work, I'm not sure if any of my projects will even run with this runtime. Hopefully, this project will turn into a proper Node replacement because the Javascript ecosystem can use a big performance boost. It'll be a while before it'll become part of any pipeline I have a say in, though.
- smrtinsert 4y ago
  Thr just reinforces the power of the java community to me. Servlet container is completely a choice built around standards unlike the js community where it still seems to be node or bust. It makes java look light years ahead of js.
- chiefalchemist 4y ago
  To your point, it would be refreshing - and appropriate - if more projects baked "documentation-first" into their purpose. For all intents and purposes it's "marketing materials". When it's lacking, as you noted, it creates doubt. "Join us?" Huh. Join what?!? This is one of engineering things that happens year over year. We all understand the value of good docs. Yet it keeps happening. Why?
  - Waterluvian 4y ago
    Docs aren’t the fun part of dev.
    - agumonkey 4y ago
      Unless you make it programmable
    - 4y ago
conaclos 4y ago
I follow bun since the start and its author has achieved a tremendous work! However, I am a bit afraid of the rapid growth of the project. I could appreciate a slower growth in order to think twice about the direction of the project. It could be terrible to have new tools' specifics in a world already crowded by them.
- lioeters 4y ago
  From the start of the project, at least from when I first saw it, it seemed to me that the author already has a long-term vision for the project, and the direction it should go. There was a list of super ambitious goals, like replacing Node.js, NPM, Webpack, etc. It's been impressive to watch how the project is making such progress in achieving them. So I think the rapid growth is a good sign that the project has communal support and momentum. I'm looking forward to seeing what Bun becomes, maybe more excited about it than Deno.
conaclos 4y ago
The post is wrong about Deno's node comparability. Deno has actually a node compat mode [1] [1] https://deno.land/manual/node/compatibility_mode https://deno.land/manual/node/compatibility_mode
- dimgl 4y ago
  True, but in practice it barely works.
- deleted 4y ago
  [deleted]
rwalle 4y ago
"No native Windows support" should be written in all caps at the beginning of the article. This is a dealbreaker for most developers working on Windows, and this project will never take off until it treats Windows as a first-class citizen. WSL helps but not everyone uses it (probably most people don't use it for regular development environment). Don't believe me? Just wait and see how this turns out in three years.
- Siilwyn 4y ago
  Are you sure? From let's say the 100 web devs I encountered the past years I remember 3 using Windows, and they all used the Linux environment for development.
- JoyrexJ9 4y ago
  Not saying you're wrong about the windows support but when it comes to WSL, my entire department uses WSL for their primary development environment
  - quickthrower2 4y ago
    Ooh. I find it a bit painful. Stuff like watching for file changes if you mount C:/ don’t work. Adds friction to web dev for sure.
    - isbvhodnvemrwvn 4y ago
      Dogshit IO performance when accessing native files makes it unusable for me.
      - JoyrexJ9 4y ago
        I suggest never access native files, if you are still keeping your code in C:\ somewhere I think you're approaching WSL the wrong way. Go all in and I've never looked back
        4y ago
rcarmo 4y ago
I’m waiting to see when it can run Node-RED (it currently can’t). Seems quite promising for embedded devices in general (again, not right now).
matesz 4y ago
Some of Bun's server speed can be attributed to uWebSockets, which has node bindings [1]. Of course this is just a small detail, since Bun is a huge project. [1] https://github.com/uNetworking/uWebSockets/discussions/1466#discussioncomment-3114410 https://github.com/uNetworking/uWebSockets/discussions/1466#...
- joshxyz 4y ago
  alex got good points here as usual. it's been a long time since i've used node's built-in http module since I've found uwebsockets.js.
  - matesz 4y ago
    Good to hear there are others successfully using uwebsockets.js! We are using it in very early stage project, not production yet. Can you share your experience using it?
    - joshxyz 4y ago
      Great experience with it. The examples in the repo, the issues and discussions sections, and the documentations are all very helpful. Alex and the other users are also quite hands-on in replying on each and every issue and discussion there. We have some thin wrapper for uWebSockets.js that lets us do the following: - parse request json - parse request multipart data - serve response json - serve response buffers - serve response streams - serve response static files - support async handler - support multiple async handlers (middlewares) links are here - https://github.com/joshxyzhimself/modules/blob/main/uwu.mjs https://github.com/joshxyzhimself/modules/blob/main/uwu.mjs - https://github.com/joshxyzhimself/modules/blob/main/uwu.d.ts https://github.com/joshxyzhimself/modules/blob/main/uwu.d.ts - https://github.com/joshxyzhimself/modules/blob/main/uwu.test.mjs https://github.com/joshxyzhimself/modules/blob/main/uwu.test... internally we just serve http, then it goes through caddy or haproxy depending on the project's needs such as tls, caching, etc. there are other similar projects too that tries to deliver express-like api: - https://github.com/kartikk221/hyper-express https://github.com/kartikk221/hyper-express - https://github.com/nanoexpress/nanoexpress https://github.com/nanoexpress/nanoexpress (defunct)
SahAssar 4y ago
Bun is currently lacking workers, which at least for me is a dealbreaker. I'd also think it'd be interesting to compare against justjs when it comes to speed, since that is a very small wrapper around V8 (much smaller than node/deno) and manages to score extremely high on techempower benchmarks (top 25 on all, first/second spot on a few): https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01...
- eatonphil 4y ago
  Just to clarify, Bun isn't a wrapper around V8. It's a wrapper around JSC. I don't think Jared's benchmarks were benchmarking Bun and Node so much as V8 and JSC. I don't think benchmarking Bun against justjs is going to change much.
  - SahAssar 4y ago
    Considering the performance difference between node, deno and justjs I don't think that's right. There is clearly a big difference between different wrappers and how to handle different things. For example some of them delegate most of HTTP handling to a native lib while IIRC node does a lot of that in its js stdlib.
  - jesse__ 4y ago
    FWIW I read it as the opposite. I think most of the stuff he benched was explicitly not benching V8 against JSC. This is all me reading between the lines .. maybe you know more about JS runtimes than I do and can confirm/deny my theories? Package manager perf: Bun (presumably) wrote a C++ or zig package manager that's integrated, and speaks NPM. I guess you could aruge that this benches their fast one against the npms V8 runtime, but.. that's a bit of a stretch for me. Copying large files: I'd be surprised if any of the benched distributions rely on the javascript runtimes to copy files on disk. HTTP Requests: Maybe distributions actually call into JSC/V8 for these .. I have no idea. I'd guess not, but this one sounds the most plausible case for "benching V8 against JSC".
- tiffanyh 4y ago
  Looks like Just-JS author is looking into swapping V8 for JSCore. I’d be super interested in seeing just how much faster Just-JS would get using JSCore (like Bun uses). https://Twitter.com/justjs14/status/1557856790897106944#m https://Twitter.com/justjs14/status/1557856790897106944#m
azangru 4y ago
> Will Bun JavaScript Take Node's Crown It's far too early to be asking this question. Deno has been around for longer, and it hasn't decrowned Node yet.
- franciscop 4y ago
  IMHO Deno's has been approaching it "wrong", so it'd never take over Node.js. Deno has 3-4 big differences over Node: url-imports/no npm, explicit permissions, web compat, typescript. As both a dev and as a package publisher, those are either not an advantage, or a straight disadvantage. npm, for all the downsides it has (and it does have them), IMHO has been a huge net positive for the JS/web community. Explicit permissions on the land of 100-dependencies is just a non-starter. Web compat is def the biggest advantage as a dev myself, but Node.js has finally woken up and catching up. I don't use TS so won't comment. IMHO the main advantage of Deno, like IO.js back then actually, has been to make Node.js stop being sluggish and actually accept PRs/new challenging features.
  - nickserv 4y ago
    I had completely given up on Node and JavaScript in general until I had a chance encounter with Typescript recently. Seriously looking at deno specifically for the built in TS support. Will never touch basic JS again.
  - crabmusket 4y ago
    From Deno's early days, it seemed their goal was to make something fairly different to Node. Holding up "had it replaced Node yet" as a yardstick seems misguided.
    - andrew_ 4y ago
      Agreed. The guy just wanted to make something he felt was better. I've never seen a mission statement that said the goals were to replace Node. It's a separate beast.
BiteCode_dev 4y ago
So after node, the ion, then the merge, then deno, now bun. JS started to get a bit sane, but I guess we are going back to fragmenting and madness pretty soon.
- andrew_ 4y ago
  Not really. Know your history first. Node split to io.js due to team disagreements and fragmentation. io.js made an immense amount of progress, adopted semver, and had all the momentum. At the time, Node was stagnant. The choice to merge was rational and good. Deno is a separate project, and while has a node compat mode, is meant to be a TS-first ecosystem with many different rules and methodologies. Bun is an experiment to see if it's possible to build node greenfield today. Only the brave will use it in prod, and only the wild mustangs of management will allow it. Try not to give into FUD. The JS universe is fine.
  - treis 4y ago
    1 GB+ files to create a react app seems pretty crazy to me. That's an order of magnitude more than Rails.
    - andrew_ 4y ago
      perfectly reasonable to choose not to use react for that reason. CRA is also known to be very bloated. See Vite et al.
franciscop 4y ago
I really hope Bun at least becomes a big player. Node.js has been very sluggish implementing new features, to the point where most people just don't trust them much anymore with this. Deno's direction is interesting but doesn't align well IMHO with dev's interests. Bun in exchange: > Out-of-the-box .env, .toml, and CSS support (no extra loaders required). This makes a lot of sense. Node.js should be "sherlocking" (integrating into the core) the most popular/common features devs use. It's crazy to me that, after 10+ years of `.env` being a common abstraction to manage environment variables, you still need to install a separated library because Node.js doesn't know to read the file itself. Same with yaml or toml. Same with features like fetch(), which took 5 years from the Issue to be implemented in Node.js (and not for lack of collaborators, but for lack of wanting to merge it). I'm happy though that Node.js is finally approving web features, and that the move to ESM has been finished, but they are moving so slow that I can def see a focused small team (might be too much for one person) overtaking Node.js.
- andrew_ 4y ago
  There's value to a system where everything is bolt-on as well.
  - t0astbread 4y ago
    I have zero experience designing systems like that but I think the sweet spot would be a standard library that's modular and detached from the core. You could pull it in after setting up the core, replace it or upgrade it in parts but it's still maintained by one entity with a consistent level of quality.
    - andrew_ 4y ago
      That's the general approach Deno has gone with. it's finding success.
  - franciscop 4y ago
    Sure, but I'd argue that value is marginal, for 90%+ of people building websites you want a straightforward HTTP server that you can build and customize with plain JS, and for some deeper cases yes then that bolt-on system is useful as well.
peanut_worm 4y ago
Well I guess Deno is dead in the water then. I have a feeling we are going to have like 10 competing JS runtimes by the end of the year.
- miralize 4y ago
  Why do you say that?
  - peanut_worm 4y ago
    If Bun gets more popular, which it seems to be, it will probably draw away a lot of people who are currently using Deno.
- eatonphil 4y ago
  Oh there are way more than 10 implementations of JavaScript before we even start counting all their distributions (Bun being a distribution of JSC, etc). https://notes.eatonphil.com/javascript-implementations.html https://notes.eatonphil.com/javascript-implementations.html
  - peanut_worm 4y ago
    Of course, but as far as general purpose runtimes go your options currently are pretty much Node, Deno, and QuickJs. Most of the other ones are for niche things like IoT or embedded systems.
    - eatonphil 4y ago
      That's not true. Take a look at the post! And look into these implementations and their users. Or don't. But don't make assertions then without looking into the facts.
      - peanut_worm 4y ago
JoyrexJ9 4y ago
I've given Bun a spin against several of my older Node.js projects and the lack of Express support killed it for me. As a drop in replacement for Node it has a long way to go. A promising start, but I'll check back in a year
- Sugimot0 4y ago
  One of the recent releases added partial express support, you might want to give it one more shot.
bamboozled 4y ago
This title is bad, it reads as if “Will Bun” might be a person.
verdverm 4y ago
What is up with buns binary config file? How does one check dependency versions and warn of security vulns? How can someone think binary format config is a good idea? (edit): https://github.com/oven-sh/bun#why-is-it-binary https://github.com/oven-sh/bun#why-is-it-binary (though this does not answer the last question, and only partially the second)
- bduffany 4y ago
  There's an option to output a yarn-compatible lockfile. In practice, I think this means you'd need a branch protection rule to disallow a change to the binary lockfile without updating the yarn lockfile. I'm not sure that complexity is worth the performance gain of the binary format, personally. I think Bun should have an option (maybe in bunrc) to always use the human-readable format, though that detracts from the "batteries included" nature a bit.
- saghm 4y ago
  Honestly, I can sort of see it making sense. The only time I need to look into my lockfile are to see the exact version of something I'm pulling in, and generally I think I would be fine doing something like `lock-file-tool --show-me xxxx`. In Rust, there's a `cargo tree` command to see the tree of your exact resolved dependencies for when you want to see the whole thing expanded, so I generally don't use the lockfile for that anyhow. I certainly don't ever update my lockfile by hand, so there'd be no loss of usability in that regard. That said, I'm not super convinced that performance would necessitate this; if parsing the text file was really that slow, I think you could instead have a separate binary file created whenever the lockfile is changed that has a serialized representation of the lockfile along with a checksum to ensure that it's not out-of-sync, then hash the lockfile before using the binary representation. I guess it's possible that if the tooling is brittle or people try to edit their lockfile by hand, this might end up detecting an out-of-sync lockfile more often than not, but at that point I think the issue isn't really with the lockfile format.
jdelman 4y ago
Betteridge’s law response to headline: no. Short answer: not any time soon. Long answer: Maybe, in the long term. Node is really entrenched in orgs and 99.999% compatibility is probably a must have before they’d would consider switching. Also, don’t underestimate the strength and persistence of Google’s V8 team. Year over year incremental performance improvements may prove to be enough to ensure Node’s dominance for another 10 years.
t0astbread 4y ago
Bun and Deno both look really impressive and I hope development in this space continues at the massive pace it's happening right now. But I've tried using both on a small greenfield project recently (nothing fancy - just a static website with some custom build logic made by stitching together some templating engines and libraries) and I ended up reaching for Node again. As mentioned in the article Bun still has a lot of incompatibilities with Node. For example, as far as I could tell scripts designed to be run with npx don't work right now. And I'm not sure what to make of binary lock files. Sure, it's more efficient but how do you know a `bun add` didn't change something it absolutely shouldn't have changed? Deno has really fast TypeScript compilation and file watching built in which is awesome. I always loathed using tsc together with nodemon or some custom file watcher thing. And permissions are great. But the package index is more or less the most valuable asset of Node and Deno doesn't provide (and doesn't aim to provide) compatibility with most of it. Also, while I do like the idea of using URLs for dependency management, the way Deno does it with import maps and lock files feels extremely convoluted and too easy to mess up for me. NPM is more intuitive.
- hayd 4y ago
  " Deno doesn't provide (and doesn't aim to provide) compatibility with most of it" which packages did you have issues with/need that didn't work? my understanding was with node compat flag deno supported quite a bit...
  - t0astbread 4y ago
    At the time it was the "tailwindcss" package IIRC. I also just tried it again on the latest iteration of that codebase and ran into some import problems, seemingly related to "markdown-it" (version 13.0.1). First I got "SyntaxError: Cannot use import statement outside a module", when I changed the package.json file to add "type: module", as requested in the error message, I got a panic. If you want, I can open an issue for that. Additionally, I'm currently using at least one function in "fs/promises" that doesn't seem to be supported yet ("opendir") and the "vm" module to evaluate some (trusted) JS. Most of those issues can be worked around, I just decided to go with Node instead for the time being.
phantomathkg 4y ago
Betteridge's law of headlines. No.
dgreensp 4y ago
Installing a gigabyte of NPM packages (or whatever is being said to be faster) a little bit faster and a little bit worse is not that interesting IMO. I actually use Deno right now because I only use a handful of third-party dependencies in my project, and I can use Deno’s bundler instead of webpack (even though that’s not its intended use). I’d rather simplify away the stuff that’s slow and complicated rather than making it faster and more complicated (less correct, less compatible).
endorphine 4y ago
When talking about JavaScript performance, aren't we essentially comparing Bun to V8? If so, wouldn't it be very hard to beat V8's performance, given that there has been so much engineering effort for many years towards making it fast? Or are we taking into account the speed of the package managers and bundlers as well? Disclaimer: I haven't saw the benchmarks, if any.
- xtian 4y ago
  Benchmarks are shown on the project’s homepage
- jesse__ 4y ago
  It's _mostly_ talking about the speed of the surrounding tools. They wrote a package manager that speaks NPM (presumably in C++ or zig instead of JS) which unsurprisingly completely dominates NPM in performance. The other stuff he benches is built into the runtime ... HTTP requests, copying files, and a webserver Bun ships with. Presumably the Bun team wrote these tools with performance in mind, but the article doesn't compare features. I'm skeptical the webserver in particular is at feature parity with the ones he benched against, which makes the numbers look pretty watery to me. It does not address the runtimes of JavaScriptCore (Webkit/Bun) vs V8 (node/deno) which, as you pointed out, are probably very similar.
- senttoschool 4y ago
  >When talking about JavaScript performance, aren't we essentially comparing Bun to V8? Bun is powered by JavascriptCore which is webkit. Webkit is developed by Apple. Safari typically outperforms Chrome on benchmarks.
- ksbrooksjr 4y ago
  For the simplest benchmarks the performance disparity might come down to the difference between JavaScriptCore (which Bun uses) and V8 (which Node uses), but for anything non-trivial there's a significant amount of overhead introduced by the Node runtime. Someone wrote a barebones V8 wrapper called Just Js, which is based on V8 just like Node, but it crushed Node in the Techempower benchmarks [1]. [1] https://www.techempower.com/benchmarks/#section=data-r21&test=plaintext https://www.techempower.com/benchmarks/#section=data-r21&tes...
cercatrova 4y ago
I have seen that while Bun is fast for startup, it performs about the same as Node and Deno for longer running tasks, simply because it just wraps JavascriptCore, which performs similarly to Node and Deno's V8.
ledgerdev 4y ago
How zig has worked out in bun as compared to how rust has worked out in deno?
JohnHaugeland 4y ago
i love how these folks are trying to blame node for create-react-app's speed issues
rubyist5eva 4y ago
> Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. Discord is a blackhole for information that search engines cannot index, it is not a replacement for documentation. I hate Discord with such a bloody passion, and this is one of the biggest reasons. People think "just ask on discord" is appropriate as a means of documentation, it absolutely is not.
wetpaws 4y ago
First thing I did is to test bun on my prod build and it crashed spectacularly. It's nowhere near being ready for any serious use.
lloydatkinson 4y ago
I think it’s really unfair to Deno as thats existed for many years and gets ignored meanwhile a hobby project is being touted as “the node replacement”.
- hu3 4y ago
  Deno is featured here frequently. Plus they had $21m in funding. I woudn't call it unfair. There's space for both.
- geodel 4y ago
  Unfair? So what would be fair? Banning articles and discussions on technologies which may compete with Deno.
notpushkin 4y ago
The article mentions Yarn, then proceeds to benchmark Bun against npm only. Not a fair comparison IMO :-)
stephen 4y ago
This is probably naive, but I'd love to see one of the Node.js competitors, i.e. Bun or Deno, innovate on the "it takes ~forever to load node_modules every time I run a test/script/etc" problem. I.e. Bun is improving "bun install" time for projects with large node_modules, and that's great, but what about, after it's on disk, having to parse+eval all of it from scratch every time I run a test? As admitted, this is a very naive ask due to the interpreted/monkey-patching nature of the JS language, but I'll hand wave with "something something v8 isolate snapshots" + "if accomplishing this requires restrictions on what packages do during module load, deno is rebooting npm anyway..." and hope someone smarter than me can figure it out. :-)
- qbasic_forever 4y ago
  Deno doesn't use node_modules so you won't have a problem there. You specify each dependency as an import URL (either in the code or in an import map) and it grabs them directly (also using a local cache directory). There's no need in the deno world to even use a package manager.
  - ch4s3 4y ago
    > There's no need in the deno world to even use a package manager That doesn't sound like I thing I would want.
    - int_19h 4y ago
      It is a package manager. It's just integrated into the runtime to the point where you import things and it "just works".
      - ch4s3 4y ago
        How does that pan out as an application grows and you're pulling in the same dep across numerous files?
        int_19h 4y ago
vips7L 4y ago
Are there any benchmarks between Bun and GraalJS?
medv 4y ago
If a title contains a question, the answer usually is No.
seizethecheese 4y ago
The “what is bun” section explained almost nothing for me. Is there a better explanation?
LAC-Tech 4y ago
I have a soft spot for bun because I like zig so much. But the key attraction of deno for me is being able to delete node_modules, package.json, package-lock.json etc etc. I don't want to bring them back.
oarabbus_ 4y ago
Not a js/frontend dev, but what I see is "47.12 percent of respondents reported to be using Node. js, while 42.62 percent were using React." Don't know if that qualifies as having the "crown".
junon 4y ago
Not until they remove URI-based imports.
riston 4y ago
The problem with Bun currently is the missing killer feature, there is no absolute reason to switch over or I might be wrong?
- brrrrrm 4y ago
  I suspect it's going to be the FFI integration. On my machine (M1 pro), Bun calling into a C library and running a no-op is 15x faster than Python calling a no-op function. V8 has never had stable bindings but Bun is changing the game with a TinyCC JIT-compiled FFI that yields a simple API. $ bun bench.js 3.5331715910204884 nanoseconds per iteration $ python3 -m timeit -s 'def f(): pass' 'f()' 5000000 loops, best of 5: 53.8 nsec per loop
russellbeattie 4y ago
This thread reminds me of the comments on Slashdot when the iPod was announced. A single guy launches an amazing project after a year of solo work. The response a month later: "No docs? Pfft. Useless."
RossH 4y ago
Fan of Deno here. You get permissions, standard library, no node_modules, Typescript, built in test, fmt and linter, auto reload for development etc. Their new “Fresh” framework is a nice touch too along with the Deno deploy infrastructure and good documentation. I’ve used it for a few projects now, no issues.
mumin 4y ago
Just bun it all to the ground.
berry_sortoro 4y ago
7speter 4y ago
I thought deno was supposed to take node’s crown first?

298 points by kiyanwang 4y ago

Node never had a crown. It’s a dirty turd.

OK now in true JS fashion, somebody make a combo of the two - Bun lacks Denos best feature which is the permission system / sandboxed by default operation - Deno lacks Bun's best feature which is backwards compatibility with NPM

matsemann 4y ago

Speed isn't really the biggest factor for most of my node usage, though. Of course, if it's a drop-in replacement one might switch. An aside, but as a non-native speaker and haven't heard of Bun before, an all-capitalized title is very confusing. "Who is Will Bun"?

papito 4y ago
Speed nowadays is almost an anti-goal. People choose the "fastest" language or framework, then add a bunch of lazy ORM queries without really knowing how to properly leverage a performant database, stitch together a bunch of "microservices", adding multiple HTTP trips across the wire, and by that time the performance of the core language is a rounding error.
- makeitdouble 4y ago
  To note, nowadays node is not just for production runtime. Anything related to tooling (compilation/check/bundling etc.) for instance will benefit from faster runtimes. Also, having a slower runtime only marginally push people to code more efficiently (e.g. people wanting to use an ORM will do so either way)
- lpapez 4y ago
  I got a PHP gig recently (after working as a Go developer for some time), and this rings very true to me. In PHP you often have to make the most of your database, and this tends to result in a far more enjoyable codebase experience.
- nickserv 4y ago
  Sure, until you're stuck on some inner loop with a poorly performing language. Of course,if you're doing microservices correctly, it should be easy to separate the parts where performance is important and write them in a language optimized for that.
  - papito 4y ago
    That is almost never used correctly. I have not seen it, for one. If it's crazy math calculations, file processing, image processing - sure, but that's not how microservices are used in 99% of the cases. It's basically an anti-pattern.
- crabmusket 4y ago
  Are you saying that performance can't be outsourced?
jraph 4y ago
Yes, I had to backtrack while parsing this sentence. Not all-capitalized would not have helped, "will" is still the first word, so would get capitalized regardless, and Bun is a proper name that would also get capitalized. It doesn't help that "bun" is a kind of bread, and is also part of the name of the "bo bun" dish. An "?" at the end would have helped a lot though.
AlfeG 4y ago
For me speed issue is totally solved by Vite. Moved whole project to it including old legacy scripts.

bongobingo1 4y ago

> Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. :-1: I loath to use discords search interface to look for information. I'm sure the Bun team doesn't see this as an end goal, but I wish forums were still a thing. At least they're mostly indexed.

toastal 4y ago
> Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority. — Matt Lee https://www.linuxjournal.com/content/opinion-github-vs-gitlab https://www.linuxjournal.com/content/opinion-github-vs-gitla...
- nickserv 4y ago
  I agree, but nobody bats an eye if your open source project is hosted on GitHub.
  - aposm 4y ago
    I see your point, and I don't use GH when I can avoid it, but those are very different in my mind. GH, for all its flaws, is a value-added hosting service on top of git. It interoperates freely with any other Git host and you can clone/pull at any time. Discord is in an entirely different category: a completely proprietary reimplementation of IRC, with rent-seeking features bolted on.
    - emkoemko 4y ago
      IRC is horrible compared to Discord at least you have a history to of chat vs nothing.
      - toastal 4y ago
        This is why SourceHut provides an IRC bouncer with its paid subscription because they are committed to the usability of IRC.

5350-uiop-1130 4y ago

another day, another javascript runtime environment

ikt 4y ago
as far as I'm aware Bun is significantly faster than others while maintaining a lot of the compatibility
- thrown_22 4y ago
- lmarcos 4y ago
  The problem of the JS ecosystem is not speed precisely.
bigDinosaur 4y ago
do we actually get many Javascript runtimes? Certainly fewer than JS frameworks.
- deleted 4y ago
  [deleted]
criley2 4y ago
Is there really that many? Outside of browsers, I know of Node, Deno and now Bun. Is there really that many serious attempts to replace node?
- v413 4y ago
  Bun is using the JavaScriptCore engine which is the Webkit/Safari Javascript engine. It is not written in Zig.
- SahAssar 4y ago
  The engine (V8 analog) is not a "Zig engine", it's javascriptcore. The wrapper is Zig, like node is C/C++ and deno is Rust.

gervwyk 4y ago

Nice article. Was listening to this chat [0] recently. Jarred Sumner is doing really cool things with this! Excited to see where it goes. [0] - https://youtu.be/rL4qpniIR7o https://youtu.be/rL4qpniIR7o

williamstein 4y ago
That’s a great interview. He sites one of his motivations for wanting to make the dev cycle faster: “if it is slow you get distracted and read Hacker News”…

jeroenhd 4y ago

There are some real obvious downsides to using this tool right now. Most importantly, the article lists there: * Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. I'm not interested in becoming part of a community, I want to use the tool. Without official docs, I'll pass until the project has matured. * Bun is not 100% compatible with Node yet. Not every npm package works. Express, for instance, is not yet functional. I don't expect full bug-for-bug Node compatibility but if extremely popular packages such as Express don't work, I'm not sure if any of my projects will even run with this runtime. Hopefully, this project will turn into a proper Node replacement because the Javascript ecosystem can use a big performance boost. It'll be a while before it'll become part of any pipeline I have a say in, though.

smrtinsert 4y ago
Thr just reinforces the power of the java community to me. Servlet container is completely a choice built around standards unlike the js community where it still seems to be node or bust. It makes java look light years ahead of js.
chiefalchemist 4y ago
To your point, it would be refreshing - and appropriate - if more projects baked "documentation-first" into their purpose. For all intents and purposes it's "marketing materials". When it's lacking, as you noted, it creates doubt. "Join us?" Huh. Join what?!? This is one of engineering things that happens year over year. We all understand the value of good docs. Yet it keeps happening. Why?
- Waterluvian 4y ago
  Docs aren’t the fun part of dev.
  - agumonkey 4y ago
    Unless you make it programmable
  - 4y ago

conaclos 4y ago

I follow bun since the start and its author has achieved a tremendous work! However, I am a bit afraid of the rapid growth of the project. I could appreciate a slower growth in order to think twice about the direction of the project. It could be terrible to have new tools' specifics in a world already crowded by them.

lioeters 4y ago
From the start of the project, at least from when I first saw it, it seemed to me that the author already has a long-term vision for the project, and the direction it should go. There was a list of super ambitious goals, like replacing Node.js, NPM, Webpack, etc. It's been impressive to watch how the project is making such progress in achieving them. So I think the rapid growth is a good sign that the project has communal support and momentum. I'm looking forward to seeing what Bun becomes, maybe more excited about it than Deno.

conaclos 4y ago

The post is wrong about Deno's node comparability. Deno has actually a node compat mode [1] [1] https://deno.land/manual/node/compatibility_mode https://deno.land/manual/node/compatibility_mode

dimgl 4y ago
True, but in practice it barely works.
deleted 4y ago
[deleted]

rwalle 4y ago

"No native Windows support" should be written in all caps at the beginning of the article. This is a dealbreaker for most developers working on Windows, and this project will never take off until it treats Windows as a first-class citizen. WSL helps but not everyone uses it (probably most people don't use it for regular development environment). Don't believe me? Just wait and see how this turns out in three years.

Siilwyn 4y ago
Are you sure? From let's say the 100 web devs I encountered the past years I remember 3 using Windows, and they all used the Linux environment for development.
JoyrexJ9 4y ago
Not saying you're wrong about the windows support but when it comes to WSL, my entire department uses WSL for their primary development environment
- quickthrower2 4y ago
  Ooh. I find it a bit painful. Stuff like watching for file changes if you mount C:/ don’t work. Adds friction to web dev for sure.
  - isbvhodnvemrwvn 4y ago
    Dogshit IO performance when accessing native files makes it unusable for me.
    - JoyrexJ9 4y ago
      I suggest never access native files, if you are still keeping your code in C:\ somewhere I think you're approaching WSL the wrong way. Go all in and I've never looked back
      - 4y ago

rcarmo 4y ago

I’m waiting to see when it can run Node-RED (it currently can’t). Seems quite promising for embedded devices in general (again, not right now).

matesz 4y ago

Some of Bun's server speed can be attributed to uWebSockets, which has node bindings [1]. Of course this is just a small detail, since Bun is a huge project. [1] https://github.com/uNetworking/uWebSockets/discussions/1466#discussioncomment-3114410 https://github.com/uNetworking/uWebSockets/discussions/1466#...

joshxyz 4y ago
alex got good points here as usual. it's been a long time since i've used node's built-in http module since I've found uwebsockets.js.
- matesz 4y ago
  Good to hear there are others successfully using uwebsockets.js! We are using it in very early stage project, not production yet. Can you share your experience using it?
  - joshxyz 4y ago
    Great experience with it. The examples in the repo, the issues and discussions sections, and the documentations are all very helpful. Alex and the other users are also quite hands-on in replying on each and every issue and discussion there. We have some thin wrapper for uWebSockets.js that lets us do the following: - parse request json - parse request multipart data - serve response json - serve response buffers - serve response streams - serve response static files - support async handler - support multiple async handlers (middlewares) links are here - https://github.com/joshxyzhimself/modules/blob/main/uwu.mjs https://github.com/joshxyzhimself/modules/blob/main/uwu.mjs - https://github.com/joshxyzhimself/modules/blob/main/uwu.d.ts https://github.com/joshxyzhimself/modules/blob/main/uwu.d.ts - https://github.com/joshxyzhimself/modules/blob/main/uwu.test.mjs https://github.com/joshxyzhimself/modules/blob/main/uwu.test... internally we just serve http, then it goes through caddy or haproxy depending on the project's needs such as tls, caching, etc. there are other similar projects too that tries to deliver express-like api: - https://github.com/kartikk221/hyper-express https://github.com/kartikk221/hyper-express - https://github.com/nanoexpress/nanoexpress https://github.com/nanoexpress/nanoexpress (defunct)

SahAssar 4y ago

Bun is currently lacking workers, which at least for me is a dealbreaker. I'd also think it'd be interesting to compare against justjs when it comes to speed, since that is a very small wrapper around V8 (much smaller than node/deno) and manages to score extremely high on techempower benchmarks (top 25 on all, first/second spot on a few): https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01...

eatonphil 4y ago
Just to clarify, Bun isn't a wrapper around V8. It's a wrapper around JSC. I don't think Jared's benchmarks were benchmarking Bun and Node so much as V8 and JSC. I don't think benchmarking Bun against justjs is going to change much.
- SahAssar 4y ago
  Considering the performance difference between node, deno and justjs I don't think that's right. There is clearly a big difference between different wrappers and how to handle different things. For example some of them delegate most of HTTP handling to a native lib while IIRC node does a lot of that in its js stdlib.
- jesse__ 4y ago
  FWIW I read it as the opposite. I think most of the stuff he benched was explicitly not benching V8 against JSC. This is all me reading between the lines .. maybe you know more about JS runtimes than I do and can confirm/deny my theories? Package manager perf: Bun (presumably) wrote a C++ or zig package manager that's integrated, and speaks NPM. I guess you could aruge that this benches their fast one against the npms V8 runtime, but.. that's a bit of a stretch for me. Copying large files: I'd be surprised if any of the benched distributions rely on the javascript runtimes to copy files on disk. HTTP Requests: Maybe distributions actually call into JSC/V8 for these .. I have no idea. I'd guess not, but this one sounds the most plausible case for "benching V8 against JSC".
tiffanyh 4y ago
Looks like Just-JS author is looking into swapping V8 for JSCore. I’d be super interested in seeing just how much faster Just-JS would get using JSCore (like Bun uses). https://Twitter.com/justjs14/status/1557856790897106944#m https://Twitter.com/justjs14/status/1557856790897106944#m

azangru 4y ago

> Will Bun JavaScript Take Node's Crown It's far too early to be asking this question. Deno has been around for longer, and it hasn't decrowned Node yet.

franciscop 4y ago
IMHO Deno's has been approaching it "wrong", so it'd never take over Node.js. Deno has 3-4 big differences over Node: url-imports/no npm, explicit permissions, web compat, typescript. As both a dev and as a package publisher, those are either not an advantage, or a straight disadvantage. npm, for all the downsides it has (and it does have them), IMHO has been a huge net positive for the JS/web community. Explicit permissions on the land of 100-dependencies is just a non-starter. Web compat is def the biggest advantage as a dev myself, but Node.js has finally woken up and catching up. I don't use TS so won't comment. IMHO the main advantage of Deno, like IO.js back then actually, has been to make Node.js stop being sluggish and actually accept PRs/new challenging features.
- nickserv 4y ago
  I had completely given up on Node and JavaScript in general until I had a chance encounter with Typescript recently. Seriously looking at deno specifically for the built in TS support. Will never touch basic JS again.
- crabmusket 4y ago
  From Deno's early days, it seemed their goal was to make something fairly different to Node. Holding up "had it replaced Node yet" as a yardstick seems misguided.
  - andrew_ 4y ago
    Agreed. The guy just wanted to make something he felt was better. I've never seen a mission statement that said the goals were to replace Node. It's a separate beast.

BiteCode_dev 4y ago

So after node, the ion, then the merge, then deno, now bun. JS started to get a bit sane, but I guess we are going back to fragmenting and madness pretty soon.

andrew_ 4y ago
Not really. Know your history first. Node split to io.js due to team disagreements and fragmentation. io.js made an immense amount of progress, adopted semver, and had all the momentum. At the time, Node was stagnant. The choice to merge was rational and good. Deno is a separate project, and while has a node compat mode, is meant to be a TS-first ecosystem with many different rules and methodologies. Bun is an experiment to see if it's possible to build node greenfield today. Only the brave will use it in prod, and only the wild mustangs of management will allow it. Try not to give into FUD. The JS universe is fine.
- treis 4y ago
  1 GB+ files to create a react app seems pretty crazy to me. That's an order of magnitude more than Rails.
  - andrew_ 4y ago
    perfectly reasonable to choose not to use react for that reason. CRA is also known to be very bloated. See Vite et al.

franciscop 4y ago

I really hope Bun at least becomes a big player. Node.js has been very sluggish implementing new features, to the point where most people just don't trust them much anymore with this. Deno's direction is interesting but doesn't align well IMHO with dev's interests. Bun in exchange: > Out-of-the-box .env, .toml, and CSS support (no extra loaders required). This makes a lot of sense. Node.js should be "sherlocking" (integrating into the core) the most popular/common features devs use. It's crazy to me that, after 10+ years of `.env` being a common abstraction to manage environment variables, you still need to install a separated library because Node.js doesn't know to read the file itself. Same with yaml or toml. Same with features like fetch(), which took 5 years from the Issue to be implemented in Node.js (and not for lack of collaborators, but for lack of wanting to merge it). I'm happy though that Node.js is finally approving web features, and that the move to ESM has been finished, but they are moving so slow that I can def see a focused small team (might be too much for one person) overtaking Node.js.

andrew_ 4y ago
There's value to a system where everything is bolt-on as well.
- t0astbread 4y ago
  I have zero experience designing systems like that but I think the sweet spot would be a standard library that's modular and detached from the core. You could pull it in after setting up the core, replace it or upgrade it in parts but it's still maintained by one entity with a consistent level of quality.
  - andrew_ 4y ago
    That's the general approach Deno has gone with. it's finding success.
- franciscop 4y ago
  Sure, but I'd argue that value is marginal, for 90%+ of people building websites you want a straightforward HTTP server that you can build and customize with plain JS, and for some deeper cases yes then that bolt-on system is useful as well.

peanut_worm 4y ago

Well I guess Deno is dead in the water then. I have a feeling we are going to have like 10 competing JS runtimes by the end of the year.

miralize 4y ago
Why do you say that?
- peanut_worm 4y ago
  If Bun gets more popular, which it seems to be, it will probably draw away a lot of people who are currently using Deno.
eatonphil 4y ago
Oh there are way more than 10 implementations of JavaScript before we even start counting all their distributions (Bun being a distribution of JSC, etc). https://notes.eatonphil.com/javascript-implementations.html https://notes.eatonphil.com/javascript-implementations.html
- peanut_worm 4y ago
  Of course, but as far as general purpose runtimes go your options currently are pretty much Node, Deno, and QuickJs. Most of the other ones are for niche things like IoT or embedded systems.
  - eatonphil 4y ago
    That's not true. Take a look at the post! And look into these implementations and their users. Or don't. But don't make assertions then without looking into the facts.
    - peanut_worm 4y ago

JoyrexJ9 4y ago

I've given Bun a spin against several of my older Node.js projects and the lack of Express support killed it for me. As a drop in replacement for Node it has a long way to go. A promising start, but I'll check back in a year

Sugimot0 4y ago
One of the recent releases added partial express support, you might want to give it one more shot.

bamboozled 4y ago

This title is bad, it reads as if “Will Bun” might be a person.

verdverm 4y ago

What is up with buns binary config file? How does one check dependency versions and warn of security vulns? How can someone think binary format config is a good idea? (edit): https://github.com/oven-sh/bun#why-is-it-binary https://github.com/oven-sh/bun#why-is-it-binary (though this does not answer the last question, and only partially the second)

bduffany 4y ago
There's an option to output a yarn-compatible lockfile. In practice, I think this means you'd need a branch protection rule to disallow a change to the binary lockfile without updating the yarn lockfile. I'm not sure that complexity is worth the performance gain of the binary format, personally. I think Bun should have an option (maybe in bunrc) to always use the human-readable format, though that detracts from the "batteries included" nature a bit.
saghm 4y ago
Honestly, I can sort of see it making sense. The only time I need to look into my lockfile are to see the exact version of something I'm pulling in, and generally I think I would be fine doing something like `lock-file-tool --show-me xxxx`. In Rust, there's a `cargo tree` command to see the tree of your exact resolved dependencies for when you want to see the whole thing expanded, so I generally don't use the lockfile for that anyhow. I certainly don't ever update my lockfile by hand, so there'd be no loss of usability in that regard. That said, I'm not super convinced that performance would necessitate this; if parsing the text file was really that slow, I think you could instead have a separate binary file created whenever the lockfile is changed that has a serialized representation of the lockfile along with a checksum to ensure that it's not out-of-sync, then hash the lockfile before using the binary representation. I guess it's possible that if the tooling is brittle or people try to edit their lockfile by hand, this might end up detecting an out-of-sync lockfile more often than not, but at that point I think the issue isn't really with the lockfile format.

jdelman 4y ago

Betteridge’s law response to headline: no. Short answer: not any time soon. Long answer: Maybe, in the long term. Node is really entrenched in orgs and 99.999% compatibility is probably a must have before they’d would consider switching. Also, don’t underestimate the strength and persistence of Google’s V8 team. Year over year incremental performance improvements may prove to be enough to ensure Node’s dominance for another 10 years.

t0astbread 4y ago

Bun and Deno both look really impressive and I hope development in this space continues at the massive pace it's happening right now. But I've tried using both on a small greenfield project recently (nothing fancy - just a static website with some custom build logic made by stitching together some templating engines and libraries) and I ended up reaching for Node again. As mentioned in the article Bun still has a lot of incompatibilities with Node. For example, as far as I could tell scripts designed to be run with npx don't work right now. And I'm not sure what to make of binary lock files. Sure, it's more efficient but how do you know a `bun add` didn't change something it absolutely shouldn't have changed? Deno has really fast TypeScript compilation and file watching built in which is awesome. I always loathed using tsc together with nodemon or some custom file watcher thing. And permissions are great. But the package index is more or less the most valuable asset of Node and Deno doesn't provide (and doesn't aim to provide) compatibility with most of it. Also, while I do like the idea of using URLs for dependency management, the way Deno does it with import maps and lock files feels extremely convoluted and too easy to mess up for me. NPM is more intuitive.

hayd 4y ago
" Deno doesn't provide (and doesn't aim to provide) compatibility with most of it" which packages did you have issues with/need that didn't work? my understanding was with node compat flag deno supported quite a bit...
- t0astbread 4y ago
  At the time it was the "tailwindcss" package IIRC. I also just tried it again on the latest iteration of that codebase and ran into some import problems, seemingly related to "markdown-it" (version 13.0.1). First I got "SyntaxError: Cannot use import statement outside a module", when I changed the package.json file to add "type: module", as requested in the error message, I got a panic. If you want, I can open an issue for that. Additionally, I'm currently using at least one function in "fs/promises" that doesn't seem to be supported yet ("opendir") and the "vm" module to evaluate some (trusted) JS. Most of those issues can be worked around, I just decided to go with Node instead for the time being.

phantomathkg 4y ago

Betteridge's law of headlines. No.

dgreensp 4y ago

Installing a gigabyte of NPM packages (or whatever is being said to be faster) a little bit faster and a little bit worse is not that interesting IMO. I actually use Deno right now because I only use a handful of third-party dependencies in my project, and I can use Deno’s bundler instead of webpack (even though that’s not its intended use). I’d rather simplify away the stuff that’s slow and complicated rather than making it faster and more complicated (less correct, less compatible).

endorphine 4y ago

When talking about JavaScript performance, aren't we essentially comparing Bun to V8? If so, wouldn't it be very hard to beat V8's performance, given that there has been so much engineering effort for many years towards making it fast? Or are we taking into account the speed of the package managers and bundlers as well? Disclaimer: I haven't saw the benchmarks, if any.

xtian 4y ago
Benchmarks are shown on the project’s homepage
jesse__ 4y ago
It's _mostly_ talking about the speed of the surrounding tools. They wrote a package manager that speaks NPM (presumably in C++ or zig instead of JS) which unsurprisingly completely dominates NPM in performance. The other stuff he benches is built into the runtime ... HTTP requests, copying files, and a webserver Bun ships with. Presumably the Bun team wrote these tools with performance in mind, but the article doesn't compare features. I'm skeptical the webserver in particular is at feature parity with the ones he benched against, which makes the numbers look pretty watery to me. It does not address the runtimes of JavaScriptCore (Webkit/Bun) vs V8 (node/deno) which, as you pointed out, are probably very similar.
senttoschool 4y ago
>When talking about JavaScript performance, aren't we essentially comparing Bun to V8? Bun is powered by JavascriptCore which is webkit. Webkit is developed by Apple. Safari typically outperforms Chrome on benchmarks.
ksbrooksjr 4y ago
For the simplest benchmarks the performance disparity might come down to the difference between JavaScriptCore (which Bun uses) and V8 (which Node uses), but for anything non-trivial there's a significant amount of overhead introduced by the Node runtime. Someone wrote a barebones V8 wrapper called Just Js, which is based on V8 just like Node, but it crushed Node in the Techempower benchmarks [1]. [1] https://www.techempower.com/benchmarks/#section=data-r21&test=plaintext https://www.techempower.com/benchmarks/#section=data-r21&tes...

cercatrova 4y ago

I have seen that while Bun is fast for startup, it performs about the same as Node and Deno for longer running tasks, simply because it just wraps JavascriptCore, which performs similarly to Node and Deno's V8.

ledgerdev 4y ago

How zig has worked out in bun as compared to how rust has worked out in deno?

JohnHaugeland 4y ago

i love how these folks are trying to blame node for create-react-app's speed issues

rubyist5eva 4y ago

> Documentation is limited, but Bun’s Discord is very active and a great source of knowledge. Discord is a blackhole for information that search engines cannot index, it is not a replacement for documentation. I hate Discord with such a bloody passion, and this is one of the biggest reasons. People think "just ask on discord" is appropriate as a means of documentation, it absolutely is not.

wetpaws 4y ago

First thing I did is to test bun on my prod build and it crashed spectacularly. It's nowhere near being ready for any serious use.

lloydatkinson 4y ago

I think it’s really unfair to Deno as thats existed for many years and gets ignored meanwhile a hobby project is being touted as “the node replacement”.

hu3 4y ago
Deno is featured here frequently. Plus they had $21m in funding. I woudn't call it unfair. There's space for both.
geodel 4y ago
Unfair? So what would be fair? Banning articles and discussions on technologies which may compete with Deno.

notpushkin 4y ago

The article mentions Yarn, then proceeds to benchmark Bun against npm only. Not a fair comparison IMO :-)

stephen 4y ago

This is probably naive, but I'd love to see one of the Node.js competitors, i.e. Bun or Deno, innovate on the "it takes ~forever to load node_modules every time I run a test/script/etc" problem. I.e. Bun is improving "bun install" time for projects with large node_modules, and that's great, but what about, after it's on disk, having to parse+eval all of it from scratch every time I run a test? As admitted, this is a very naive ask due to the interpreted/monkey-patching nature of the JS language, but I'll hand wave with "something something v8 isolate snapshots" + "if accomplishing this requires restrictions on what packages do during module load, deno is rebooting npm anyway..." and hope someone smarter than me can figure it out. :-)

qbasic_forever 4y ago
Deno doesn't use node_modules so you won't have a problem there. You specify each dependency as an import URL (either in the code or in an import map) and it grabs them directly (also using a local cache directory). There's no need in the deno world to even use a package manager.
- ch4s3 4y ago
  > There's no need in the deno world to even use a package manager That doesn't sound like I thing I would want.
  - int_19h 4y ago
    It is a package manager. It's just integrated into the runtime to the point where you import things and it "just works".
    - ch4s3 4y ago
      How does that pan out as an application grows and you're pulling in the same dep across numerous files?
      - int_19h 4y ago

vips7L 4y ago

Are there any benchmarks between Bun and GraalJS?

medv 4y ago

If a title contains a question, the answer usually is No.

seizethecheese 4y ago

The “what is bun” section explained almost nothing for me. Is there a better explanation?

LAC-Tech 4y ago

I have a soft spot for bun because I like zig so much. But the key attraction of deno for me is being able to delete node_modules, package.json, package-lock.json etc etc. I don't want to bring them back.

oarabbus_ 4y ago

Not a js/frontend dev, but what I see is "47.12 percent of respondents reported to be using Node. js, while 42.62 percent were using React." Don't know if that qualifies as having the "crown".

junon 4y ago

Not until they remove URI-based imports.

riston 4y ago

The problem with Bun currently is the missing killer feature, there is no absolute reason to switch over or I might be wrong?

brrrrrm 4y ago
I suspect it's going to be the FFI integration. On my machine (M1 pro), Bun calling into a C library and running a no-op is 15x faster than Python calling a no-op function. V8 has never had stable bindings but Bun is changing the game with a TinyCC JIT-compiled FFI that yields a simple API. $ bun bench.js 3.5331715910204884 nanoseconds per iteration $ python3 -m timeit -s 'def f(): pass' 'f()' 5000000 loops, best of 5: 53.8 nsec per loop

russellbeattie 4y ago

This thread reminds me of the comments on Slashdot when the iPod was announced. A single guy launches an amazing project after a year of solo work. The response a month later: "No docs? Pfft. Useless."

RossH 4y ago

Fan of Deno here. You get permissions, standard library, no node_modules, Typescript, built in test, fmt and linter, auto reload for development etc. Their new “Fresh” framework is a nice touch too along with the Deno deploy infrastructure and good documentation. I’ve used it for a few projects now, no issues.

mumin 4y ago

Just bun it all to the ground.

berry_sortoro 4y ago

7speter 4y ago

I thought deno was supposed to take node’s crown first?