Bun.js is the newest member of the JavaScript family. Now, what makes developers excited about the bun? Do you know the answer? No? Then, through this blog, I am explaining about the Bun Framework.
What is Bun?
The definition of Bun is “a fast all-in-one JavaScript runtime”.
Bun features a native bundler that converts the dev codes/files into minified and merged (bundled) output files, a task runner for automating repetitive tasks, and a transpiler, which transforms one source code into another before execution. Other notable features include support for a range of Node and web APIs; the ability to use NPM, Node.js’ package manager; and increased performance, according to the Bun websites.
Amazing performance makes it special.
There are certain quick benchmarks created by the contributors of Bun:
- 14x faster than Next.js for reloading CSS
- Dist and node_modules are cleaned within a couple of seconds.
Jarred Sumner, a former front-end engineer at Stripe is the founder of Bun Framework. Bun was released publicly in 2022.
Bun aims that “it runs the world’s most of the JavaScript outside of browsers, bringing performance and complexity enhancements for your future infrastructure, as well as developing productivity through better and simpler tools,” These are the words spoken by Mr Sumner said in an interview, conducted by Ping Labs CEO Theo Browne telecasted in Youtube.
Advantages of Bun.js:
It was built to focus on three main things:
- Fast speed
- High-performance (extending JavaScriptCore, the engine).
- Comprehensive tools (bundler, transpiler, package manager).
Bun vs Node vs Deno:
Bun, just like Node and Deno, is a JavaScript runtime. But it claims to offer more features and performance than Node.js and Deno. It is faster, and Bun is compatible with Node such as node modules, node APIs, etc.
Bun is built on JavaScriptCore whereas Node and Deno use V8 as their primary JavaScript execution engines. JavaScript engines at the end of the day are supposed to run JavaScript but Apple JavaScriptCore is vastly superior to Google V8. JavaScriptCore has proven itself to be faster, and more secure compared to google v8. Google V8 is slower and a bit glitchy (not to mention that it uses a massive amount of RAM and CPU) and is one of the components of Google’s tracking systems, so it violates user privacy.
Bun, however, comes with a lot of tooling baked in, a lot of speed, and a bunch of convenient practices.
Comparatively, Node.js is slower than Deno and Bun. The newer runtimes are between 2 to 3 times faster than the market leader, Node.js. Node.js offers about 75K Receive Packet Steering (RPS), while Deno goes around 180K and Bun goes around 195K. This is a huge difference.
Bun framework and Deno have similar performance however, 180K vs 195K isn’t a big difference. Deno uses flash server API Deno.serve and it performs pretty well.
Ultimately, Bun’s CPU usage is the same as others. However, Bun exhibits excellent performance since it utilizes less system resources and memory.
Why is Bun fast?
The Bun team attributes their performance:
- Tons of time was spent profiling, benchmarking, and optimizing.
- Using Zig, a general-purpose programming language, adds to its low-level memory control and lack of hidden control flow. No hidden memory allocations. No preprocessor, no macros.
- Bun uses JavaScriptCore engine which is the engine used in Safari hence it performs faster than V8, which powers Google Chrome.
Setup:
To install Bun you need to execute the following commands:
curl -fsSL https://bun.sh/install | bash
# Manually add the directory to your $HOME/.bashrc (or similar)
BUN_INSTALL=”/home/jgranja/.bun”
PATH=”$BUN_INSTALL/bin:$PATH”
To check the version:
bun –version
You will notice that it has not reached the 1.0.0 version yet. It is still not production ready.
Conclusion
Certainly, Bun is new, and it has bugs but there are a lot of expectations placed on it from both Sumner and developers. Sumner is aware of this and attributes a portion of its flaws to the absence of widespread testing. Of this, he says, “bun doesn’t have enough test coverage and that’s why it’s so buggy.” Sumner stated, “I’ve been coming from the perspective of ‘it needs to work as much as possible with the existing ecosystem because people shouldn’t have to rewrite their code’ but maybe I should start thinking more about what if we make/what new things are possible because the APIs bun enables.”
If you want to know more about it, reach us.
