You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2024-05-03-bunjs-a-fast-rising-star.md
+27-27Lines changed: 27 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,16 @@
1
1
---
2
-
title: BunJS - A fast-rising star?
2
+
title: Bun - A fast-rising star?
3
3
date: 2024-05-03 00:00:00 Z
4
4
categories:
5
5
- Tech
6
6
tags:
7
7
- javascript
8
-
- typescript
9
-
- NodeJS
10
-
- BunJS
8
+
- TypeScript
9
+
- Node.js
10
+
- Bun
11
11
- Christmas
12
12
author: wmckenzie
13
-
summary: A (belated) festive look at the latest challenger to NodeJS's throne
13
+
summary: A (belated) festive look at the latest challenger to Node.js's throne
14
14
---
15
15
16
16
<style>
@@ -24,21 +24,21 @@ summary: A (belated) festive look at the latest challenger to NodeJS's throne
24
24
25
25
## A trip down memory lane...
26
26
27
-
Last year I attended the Infobip Shift conference, where I saw a talk by Tejas Kumar on “[New Trends in Front-End Development](https://www.youtube.com/watch?v=VINfWbaFBVs&list=PLuAItjWV4peETEf336UJKvDsI5RWbshUa&index=31&pp=iAQB)”. In his talk, he demoed building and running a new QwikJS app using Bun instead of Node. I’d been hearing lots of talk about Bun, particularly on the Bytes email blast but hadn’t had a chance to properly check it out so I was particularly interested in seeing how it did.
27
+
Last year I attended the Infobip Shift conference, where I attended a talk by Tejas Kumar on “[New Trends in Front-End Development](https://www.youtube.com/watch?v=VINfWbaFBVs&list=PLuAItjWV4peETEf336UJKvDsI5RWbshUa&index=31&pp=iAQB)”. In his talk, he demoed building and running a new Qwik app using Bun instead of Node.js. I’d been hearing lots of talk about Bun, particularly on the Bytes email blast but hadn’t had a chance to properly check it out so I was particularly interested in seeing how it did.
28
28
29
-
BunJS is billed as “a fast Javascript all-in-one toolkit”... they’re definitely not lying about the fast part! When he first ran the command to start the app up my colleague and I both looked at each other in amazement and commented “Wow that was fast” (content edited for a PG rating). There wasn’t much more discussed about Bun in the talk, the focus was more on Qwik and its approach to Signals, and how that compared to other frameworks (a topic for another time), but my interest was certainly piqued.
29
+
Bun is billed as “a fast JavaScript all-in-one toolkit”... they’re not lying about the fast part! When he first ran the command to start the app up my colleague and I both looked at each other in amazement and commented: “wow that was fast” (content edited for a PG rating). There wasn’t much more discussed about Bun in the talk, the focus was more on Qwik and its approach to Signals, and how that compared to other frameworks (a topic for another time), but my interest was certainly piqued.
30
30
31
-
The problem I was struggling to solve was; “What can I use this on?”. Our client work would be an ideal candidate, we certainly saw issues with NodeJs slowness that Bun definitely had the potential to help with, however in the world of Fintech new and fancy also means unknown and risky and adopting new tech can be a hard case to make.
31
+
The problem I was struggling to solve was: “what can I use this on?”. Our client work would be an ideal candidate, we certainly saw issues with Node.js slowness that Bun had the potential to help with, however in the world of Fintech, new and fancy also means unknown and risky, and adopting new tech can be a hard case to make.
32
32
33
33
34
34
35
-
Then we got to October, and, to my eternal annoyance, Christmas stuff started appearing in the shops (thankfully no Mariah yet), and, despite myself, I started thinking about Christmas things, and more specifically… [Advent of Code](https://adventofcode.com/). For those currently sitting scratching their heads, Advent of Code is a global series of coding challenges, one a day from the start of December until Christmas Day, set by [Eric Wastl](http://was.tl/), which I took part in for the first time the year before. I’d managed a respectable 6th place on the Scott Logic leaderboard and a slightly better 5th place on the client leaderboard. This year I was hoping to improve on that.
35
+
Then we got to October and, to my eternal annoyance, Christmas stuff started appearing in the shops (thankfully no Mariah yet). Despite myself, I started thinking about Christmas things, and more specifically… [Advent of Code](https://adventofcode.com/). For those currently sitting scratching their heads, Advent of Code is a global series of coding challenges, one a day from the start of December until Christmas Day, set by [Eric Wastl](http://was.tl/). I'd taken part for the first time the year before and managed a respectable 6th place on the Scott Logic leaderboard and a slightly better 5th place on the client leaderboard. This year I was hoping to improve on that.
36
36
37
37
## Formulating a plan
38
38
39
-
Last year’s efforts I’d written in Python, as a way of keeping my hand in. For the most part, it worked fine but some of the more intensive data processing challenges were painfully slow to run, despite my best efforts at optimising, to the point where, having confirmed that we were basically running the same algorithm, I was using my line manager’s Rust versions to get the final answers. Suffice to say, this year I needed something better. I’d been considering writing in Rust, both because of its obvious performance advantage, and because I’d like to get better at Rust, but my lack of familiarity, combined with the knowledge that the faster you solve the puzzle the more points you get, was giving me trepidation… was BunJS a possible solution? More research was needed!
39
+
My first attempts were written in Python, as a way of keeping my hand in. For the most part, it worked fine but some of the more intensive data processing challenges were painfully slow to run, despite my best efforts at optimising. There were points where having confirmed that we were basically running the same algorithm, I was using my line manager’s Rust versions to get the final answers. Suffice to say, this year I needed something better. I’d been considering writing in Rust, both because of its obvious performance advantage, and because I’d like to get better at Rust. My lack of familiarity, however, combined with the knowledge that the faster you solve the puzzle the more points you get, was giving me trepidation… was Bun a possible solution? More research was needed!
40
40
41
-
I decided to take my existing solutions from last year and convert them to Typescript, then benchmark them against the Python versions, and while I was at it, why not compare NodeJS running the same code? The results... were surprising:
41
+
I decided to take my existing solutions from last year and convert them to TypeScript, then benchmark them against the Python versions, and while I was at it, why not compare Node.js running the same code? The results... were surprising:
42
42
43
43
## The results are in
44
44
@@ -47,37 +47,37 @@ I decided to take my existing solutions from last year and convert them to Types
47
47
| Language | Day 10 | Day 11 | Day 12 | Day 13 | Day 14 | Day 15 | Day 16 |
> N.B. For the purposes of keeping the table concise I've focused on a week's worth of tasks in the middle of the month, this gave me problems with a reasonable degree of difficulty but not ones that would be difficult to re-engineer in Typescript. I've also only included the average total time to load data and complete both parts of each problem across 3 runs, rather than comparing each individual segment.
54
+
> N.B. For the purposes of keeping the table concise I've focused on a week's worth of tasks in the middle of the month. This gave me problems with a reasonable degree of difficulty but not ones that would be difficult to re-engineer in TypeScript. I've also only included the average total time to load data and complete both parts of each problem across 3 runs, rather than comparing each individual segment.
55
55
56
-
There's certainly no clear, runaway winner. I'd expected Python to still be the faster option, with BunJS maybe coming close, while still beating NodeJS across the board. However, as we can see, things weren't quite so clear-cut.
56
+
There's certainly no clear, runaway winner. I'd expected Python to still be the faster option, with Bun maybe coming close, but both beating Node.js across the board. However, as we can see, things weren't quite so clear-cut.
57
57
58
-
BunJS actually managed to outperform Python across the majority of the examples, with 3 wins to Python and NodeJS's 2s. Even expanding this out to the first 16 days BunJS stays ahead with 10 total wins, beating Python's 5 and NodeJS's 1. Perhaps most interesting was the fact that calling Bun via NPM performed the best, taking
58
+
Bun actually managed to outperform Python across the majority of the examples, with 5 total wins to Python's 2. Even expanding this out to the first 16 days, Bun stays ahead with 10 total wins, beating Python's 5 and Node.js's 1. Perhaps most interesting was the fact that calling Bun via NPM performed the best, taking
59
59
6 wins to the direct approach's 4. I would've expected the extra overhead to have a negative impact. Admittedly there may have been some skewing of data on this, the run
60
60
times via NPM mostly tended to decrease on each execution, suggesting a degree of caching may be taking place.
61
61
62
-
Also pretty impressive is that both BunJS and NodeJS managed to produce a result on Day 15 where Python continued to crash out. Granted there's probably a flaw in my Python code
63
-
but the Typescript code is pretty much a like-for-like conversion. I also felt like BunJS' perceived load time was faster, even on solutions where Python had the
64
-
fastest execution time, the time from pressing enter to starting to getting output often seemed quite long, with BunJS feeling much more responsive.
62
+
Also pretty impressive is that both Bun and Node.js managed to produce a result on day 15 where Python continued to crash out. Granted there's probably a flaw in my Python code,
63
+
but the TypeScript code is pretty much a like-for-like conversion. I also felt like Bun's perceived load time was faster, even on solutions where Python had the
64
+
fastest execution time, the time from pressing enter to starting to seeing output often seemed quite long, with Bun feeling much more responsive.
Let's start with the main question, is BunJS faster than NodeJS? The results would suggest that on average, yes, BunJS executes the same code faster than NodeJS.
70
+
Let's start with the main question, is Bun faster than Node.js? The results would suggest that on average, yes, Bun executes the same code faster than Node.js.
71
71
72
-
Should you immediately switch all NodeJS projects to BunJS? Probably not, while BunJS was faster, I would say the differences are not really great enough to warrant the
73
-
overhead of any refactoring, however minor. I also hit a scenario in last year's Advent of Code where BunJS couldn't run the solution due to import issues, but NodeJS could,
72
+
Should you immediately switch all Node.js projects to Bun? Probably not, while Bun was faster, I would say the differences are not really great enough to warrant the
73
+
overhead of any refactoring, however minor. I also hit a scenario in last year's Advent of Code where Bun couldn't run the solution due to import issues, but Node.js could,
74
74
so you may find that converting to Bun will break your project.
75
75
76
-
Should I consider BunJS when starting a new project? Absolutely! For most use cases you're unlikely to have an issue, and transitioning back to NodeJS should be relatively
77
-
straightforward, should you need to. The out-of-the-box Typescript and ESM handling is especially nice, I found I had a lot of headaches with ESM typescript loaders trying to
78
-
make the scripts run via NodeJS without compiling, and faster startup times for your application are never a bad thing.
76
+
Should I consider Bun when starting a new project? Absolutely! For most use cases you're unlikely to have an issue, and transitioning back to Node.js should be relatively
77
+
straightforward, should you need to. The out-of-the-box TypeScript and ESM handling is especially nice, I found I had a lot of headaches with ESM TypeScript loaders trying to
78
+
make the scripts run via Node.js without compiling, and faster startup times for your application are never a bad thing.
79
79
80
-
Should I switch all my Python projects to BunJS? Again, probably not. Python is still really fast, and, particularly for these kinds of problems, there are a lot of packages
80
+
Should I switch all my Python projects to Bun? Again, probably not. Python is still really fast, and, particularly for these kinds of problems, there are a lot of packages
81
81
available to make implementing the more complex algorithms a lot easier, and as I found with last years challenges, sometimes Python can handle the bigger datasets a lot better.
82
82
83
83
Should I do Advent of Code? Absolutely, while some days puzzles are downright horrible, for the most part it's pretty fun, and you can learn a lot about algorithms and more
0 commit comments