About: I love coding, 3D designing, and listening to music.
I'm currently a fanatic about Rust, TypeScript, and Next.js.
Christian, Coder, Creator
Location:
Earth
Joined:
Oct 24, 2023
npm is SLOW! This is better 🍞
Publish Date: Nov 24 '24
54 18
Let's face it: we've all waited way too long for npm install to finish. Whether you're racing against a deadline or just impatient (like me), slow install times are quite annoying.
Enter Bun, the super fast alternative to npm that's making quite a stir in the JavaScript world. 🚀
(If you clicked on this post because of the cover image, now you know — it was a reference to Bun).
What is Bun?
Bun isn't just another package manager — it's a performance-focused runtime built from the ground up with speed in mind. Instead of relying on Node.js's V8 (which is also used by Chromium), Bun uses JavaScriptCore (from WebKit), giving it an edge in raw performance. This translates to dependency installations that are up to 29x faster than npm, 17x faster than pnpm, and 33x faster than Yarn. Yes, you read that right: 29 times faster. 🔥
Why is Bun so Fast?
Bun's core is written in Zig, a low-level language that ensures efficient memory management.
Bun doesn't need separate tools for bundling, transpiling, or hot reloading, as they're all built-in, reducing overhead.
Unlike npm's package-lock.json, Bun uses bun.lockb, designed for speed and minimal file conflicts.
Key Features of Bun:
Blazing-fast Installs: Run bun install and see your dependencies appear almost instantly.
Built-in Bundler: No more juggling Webpack or Vite — it's all here. Bun builds 188x faster (over one hundred times faster) than rollup with terser and about 2x faster than modern builders like esbuild.
Faster CI/CD: Say goodbye to painfully slow dependency setups in your pipelines.
Secure: Bun only runs lifecycle scripts for trusted dependencies, unless explicitly approved.
Getting Started with Bun
Switching to Bun is super simple. Support for Windows was recently released (see bun.sh), but here's how to use it on macOS and Linux:
1. Install Bun:
curl -fsSL https://bun.sh/install | bash
2. Remove existing lock files:
rm package-lock.json yarn.lock pnpm-lock.yaml
3. Remove node_modules:
rm-rf node_modules
4. Install dependencies:
bun install
Prepare to be amazed. 🤯
My own experience
I heard a lot about Bun and couldn't resist trying it.
I've already tested pnpm (pretty good!), yarn (alright), etc. before, but Bun had some (extremely!) awesome looking benchmarks!
Well, I opened up a giant top-secret project (I'm posting about that soon! 🤫) with lots of dependencies. First, let's try npm install… Oh, well, it froze. So let's cancel it and try again (npm gets a head-start!):
To be fair, 421 dependencies is a lot (now none of you will want to use my app). But let's see how Bun handles this (no head-starts!):
So npm took 20 seconds. Bun took 0.7 seconds.
WOW! I was impressed. You will be, too.
Final Thoughts
Bun isn't just faster — it's a productivity booster. If you're tired of staring at a terminal, waiting for npm to do its thing, give Bun a try. It's simple, secure, and stupidly fast. 🍞
Bun isn't just a package manager!
Bun includes a testing framework that’s several times faster than Vite and Jest, a compiler, executable builder, and more!
Bun reduces dependency size (like pnpm)!
You might have heard good things about pnpm, which uses symlinks to reduce the size of node_modules folders (which are usually gigantic).
Bun optimizes node_modules size too, and it's faster (and easier to type 😂).
This is a #discuss post! I kept it fairly short because I want you to comment and tell me what you think. What package manager do you use? Have you tried Bun? (Do you even use JavaScript)? Let me know in the comments!
I am use npm. But I do not install npm directly, I am using nvm that handel multiple version of npm. It's so simple to handel multiple project those are build using different version of node without docker container. Now my question is if I have multiple project those are use different version of node then can I handel it with bun?
nvm doesn't make npm any faster (it's just different npm environments) but it is certainly very useful!
When I used npm I used nvm too.
I don't think there is a Bun equivalent (to be clear: nvm is not by npm and does not come with it; it's a third-party thing), though you can globally install bun with npm and use different versions of bun that you have installed in your different npms. (Obviously that's pretty annoying to deal with).
This installation will install bun for you and also bum altogether.
Windows
I only own a Mac, so I can't test at all if Windows is working, and I can't write a script to auto-install on Windows as well. So here are a few instructions on how to install Bum for Windows:
pointless:
there are hundreds of articles that speak about bun in a way more precise and correct way, you barely scratched the surface and if that was the point it could just have been a tweet.
uninformed:
it seems a bit of a copy paste or maybe AI generated?
a low-level language that ensures efficient memory management. this is wrong, efficient? not really is more manual than you expect to manage memory in zig.
Built-in Bundler: No more juggling Webpack or Vite
this is just untrue, if you need to build a FE project you should need one of those, you just run it via bunx
Faster CI/CD: Say goodbye to painfully slow dependency setups in your pipelines.
this could say that is related to the fact that installs are faster, but if you cached deps it wont matter, so it is a bit of a stretch.
Bun optimizes node_modules size too what does this mean? how does it optimises it? do you mean dumps everything in a shared space and symlink unless you have workspaces? that is something that every other package manager does too.
clickbaity:
THIS IS BETTER!
this is the typical example of a clickbaity article, and the thing that I hate the most from the dev community around all of the social media.
If you had called this post: My first Impressions on Bun I would not have been so annoying about everything else.
Thank you for your feedback. I would like to touch on different parts of this to help you understand my intent with this post.
Firstly, the post has a low experience level target audience.
I “barely scratched the surface” because this targets a lesser-experienced audience, or people who haven't heard about Bun already.
If you don't want to read as many posts like this, just change your experience settings here: dev.to/settings/customization
Secondly, my post is not uninformed. I could have gone into a lot more detail if I wanted, but I didn't. The post is not copy-pasted or AI-generated (or AI assisted).
Zig is efficient. It does not have a garbage collector (many low-level languages do not), but that means you get to customize how memory is allocated and managed. Read the Zig docs
Many projects can quite easily be bundled using Bun. I've used it myself on a lot of TS/JS projects, and it works great. You can see the docs for bun build here: bun.sh/docs/bundler
Bun isn't just faster because of caching. I've tested this myself. For example, Bun moves package file deletion to a separate thread so it doesn't block the main thread, deduplicated dependencies in the cache (other caches don't), and more.
You clearly don't understand this. npm does not symlink packages. That's the whole reason why pnpm and yarn Plug'n'Play were created. Bun basically does the same optimizations as pnpm, but more efficiently, and faster.
Thirdly, my post did not say THIS IS BETTER!. It said This is better 🍞, so please don't exaggerate. 🙂
Sometime, I'll go into more detail about this in a DEV post, but not all things that get called 'clickbait' are bad. Clickbait means “content whose main purpose is to attract attention and encourage visitors to click on a link to a particular web page.”
Is there anything wrong with attracting attention or encouraging visitors to click on a link? No.
Where I draw the line is when clickbait become deceptive or promises something is does not give. My post is technically 'clickbait', but it is not deceptive or dishonest.
My title creates three claims (with some implied interpretations):
npm is slow (relative to an alternative)
this is better (an alternative is better)
It's implied that my post will discuss the claims in the title
Since it's true that npm is slow, Bun is better and faster, and my posts discusses this, I don't see how my title is bad.
I know it's quite easy to become annoyed at all clickbait because lots of clickbait is bad.
It would have been nice if you could have elaborated in your first comment, instead of calling my post pointless and uninformed without backing up your claims.
Still, I'll remember this in future posts, as my goal isn't to create clickbait, it's to create good quality content for whatever experience level I'm writing for to read.
I hope this clarifies some things for you, have a great week!
Yes Bun has some upsides, but there are some downsides, too.
First, it is insecure by definition. Zig is not in a V1 yet as it still needs to fix some of the security issues and be fully tested. As Bin heavily builds upon these non-v1 standard libs it also must be considered insecure for now. This already disqualifies it from running in CI/CD pipelines let alone a standalone server (in enterprise environments).
Even ignoring this it still has to be en par in terms of features. For instance, last time I checked private npm registries (such as Azure artifacts) have not been working.
The third point I want to mention is that some parts of the tool chain (such a the bundler) are either incomplete and/or don't give much log output. The last time I worked with the bundler it just failed silently and there was no way to get any information out what's wrong.
So yeah a year ago it was the hot shit, but it did not really complete it's mission as of today. Still worth keeping it on the radar!
Just because Zig is not version 1 and not inherently secure does not mean anything built with it will be insecure.
In fact, Bun takes extra measures to be more secure than other package installers. For example, npm automatically executes any script in the postinstall field of the package.json for a dependency when you install the package. Bun only runs the postinstall scripts for trusted packages.
Yeah, Bun is missing some features. (The point of my post is that it's fast).
Just because Zig is not version 1 and not inherently secure does not mean anything built with it will be insecure.
Well depends. I am in particular referring to the http lib - so sure, if you avoid such things than you avoid the parts that need more hardening. But then again - pretty much everything uses these underlying libs (remember you need the http lib already to retrieve packages...) - and Bun did not rewrite any of those. So no - you are definitely not right. Issues in the underlying Zig libs are not patched in Bun (how / why should they - most of the time its unknown issues) and will bubble up.
(I love Zig and I bullish on it - so for me this uncertainty is not at all a problem; but its something you need to be aware about and that companies care about a lot)
The bundler works awesome for me!
Happy to hear they made progress on error output. Still output is sparse (the error log should not be the first thing you see). Not sure if it can be used programmatically already and if plugins are already in.
At my old company, we used to have Front-End meetups and one person broke down the install time differences and I've been convinced since then. But I have yet to try it out. 🤦🏿♂️ I think you have finally pushed me to give it a go. 🙌🏿
i dont use npm just plain JS :)