[FEATURE] Investigate bun if it's right for glee

[KhudaDad414]

Why do we need this improvement?

some of the features that bun provides seems to be the tool for glee.
Some reasons that I think bun would be a great choice for us.

1. built in Typescript support.
2. fast dependency install.
3. fast built-in HTTP and Websocket Servers.
4. built-in test runner.

How will this change help?

It will help make glee more stable and more developer friendly.

Screenshots

No response

How could it be implemented/designed?

by using bun as a package-manager, runtime and tester.

🚧 Breaking changes

CI/CD pipeline might not work with bun.

👀 Have you checked for similar open issues?

• I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue?

Yes I am willing to submit a PR!

[Souvikns]

Looks interesting, were you able to create a build using bun, I tried to create a build of glee and it didn't work, do we have to update the codebase to use bun?

[KhudaDad414]

@Souvikns I am trying to see if #795 is feasible I used bun and the result seems promising.

I used Bun alongside its WebSockets implementation with glee. (doing (almost) all of the things that Glee does, including message payload validation, headers validation, query validation, and other things...)

This is what I got:

using bun runtime and Bun.serve as the WebSocket server:

Connecting 32 WebSocket clients...
[204.69ms] All 32 clients connected
173409 messages per second (32 clients x 1600 msg, min delay: 64ms)
186358 messages per second (32 clients x 1600 msg, min delay: 64ms)
188732 messages per second (32 clients x 1600 msg, min delay: 64ms)
190166 messages per second (32 clients x 1600 msg, min delay: 64ms)
185823 messages per second (32 clients x 1600 msg, min delay: 64ms)
174429 messages per second (32 clients x 1600 msg, min delay: 64ms)
181435 messages per second (32 clients x 1600 msg, min delay: 64ms)
189214 messages per second (32 clients x 1600 msg, min delay: 64ms)
168834 messages per second (32 clients x 1600 msg, min delay: 64ms)
203022 messages per second (32 clients x 1600 msg, min delay: 64ms)
10 runs
[
  173409,
  186358,
  188732,
  190166,
  185823,
  174429,
  181435,
  189214,
  168834,
  203022
]

using current implementation:

Connecting 32 WebSocket clients...
[210.90ms] All 32 clients connected
9582 messages per second (32 clients x 1600 msg, min delay: 64ms)
9827 messages per second (32 clients x 1600 msg, min delay: 64ms)
10638 messages per second (32 clients x 1600 msg, min delay: 64ms)
9951 messages per second (32 clients x 1600 msg, min delay: 64ms)
10824 messages per second (32 clients x 1600 msg, min delay: 64ms)
10174 messages per second (32 clients x 1600 msg, min delay: 64ms)
10106 messages per second (32 clients x 1600 msg, min delay: 64ms)
10867 messages per second (32 clients x 1600 msg, min delay: 64ms)
10261 messages per second (32 clients x 1600 msg, min delay: 64ms)
11131 messages per second (32 clients x 1600 msg, min delay: 64ms)
10 runs
[
  9582,
  9827,
  10638,
  9951,
  10824,
  10174,
  10106,
  10867,
  10261,
  11131
]

as you can see bun is 1781.54% faster for us. you read it right, ONE THOUSAND SEVEN HUNDRED percent faster.

Maybe the final implementation isn't that fast and I have missed a crucial thing in my implementation and the final number may be way lower than this, but DAMN that is fast.

plus, native typescript support, ultra-fast package manager, etc...

[fmvilas]

My only concern is that we won't be using what our users will be using, i.e., npm. So we won't be able to feel the pain they feel and, therefore, we'll not solve it for them.

[KhudaDad414]

My only concern is that we won't be using what our users will be using, i.e., npm. So we won't be able to feel the pain they feel and, therefore, we'll not solve it for them.

bun has its own runtime and it doesn't run on node.js. the bigger question is the performance improvements and a better developer experience are worth it for our users to use bun runtime.

[fmvilas]

So our users would have to use Bun as well? They could not use npm?

[KhudaDad414]

@fmvilas
Bun will replace a few things:

1. As a runtime it will replace node.js and give us the following benefits:

   • It's Websocket and HTTP implementation is so much faster than node (almost as fast as C++), as demonstrated here.
   • Native typescript support. (so better developer experience)

2. As a package manager it will replace NPM CLI (users can still use 'NPM' but as you said, we won't feel their pain with NPM).

3. As a test runner it will replace jest.

So our users would have to use Bun as well? They could not use npm?

No, If we want to use Bun's WebSocket and HTTP server implementation and typescript support, then we have to drop node.js entirely.

We can still use it as a test runner and a package manager with Node and it will run on Node.js (Which isn't that easy to justify, they are supposed to be super fast though.).

I am strongly in favour of going all the way and dropping Node.js. Not sure if it would be a deal breaker for our user.

[fmvilas]

Not sure if it would be a deal breaker for our user.

First of all, we need to find out this. We need to be pretty sure it won't compromise our users and they could continue with npm, pnpm, etc.

I am strongly in favour of going all the way and dropping Node.js.

Watch out, we shouldn't be dropping Node.js support because that's what the majority of our users are using. Big majority actually. Probably around 99%. I know you're getting excited about Bun and its results but Oven (the creators of Bun) is a company backed by VCs. That will put a lot of pressure on them to monetize their users and it's not clear how they'll do it so I'd be careful to quickly jump on it.

Also, we're an open source project in an open governance community. Don't you think we should try to support the other open source projects (Node.js) whenever possible? I know it's a lot of an opinion but that counts a lot IMHO.

users can still use 'NPM' but as you said, we won't feel their pain with NPM

I would not dismiss this point or take it lightly. It's highly important, especially now that we have a DX working group. How are we gonna make sure our users have a great user experience if don't get to experience the same as them?

---

I'm not a maintainer and you guys can decide whatever you want but if you asked me, this should be a big "no" for now. I'd wait a few more years and see where this Bun trend is going to instead of jumping quickly on the bandwagon of the excitement.

[KhudaDad414]

@fmvilas valid points. gonna revisit this idea in a while. 🙇

[fmvilas]

Thanks for reconsidering it, @KhudaDad414 🙏

[jbool24]

FWIW, my two cents are to tread lightly with Bun still. As @fmvilas highlights its VC backed so there are some risks swimming around in all those proposed performance and DX gains. They may be forced to monetize in a way that makes usage costs prohibitive to "less than enterprise" teams. If they are forced to build a walled-garden to survive and maximize investor returns then it would put this project at risk too and minimizing the market share of who could use Glee. Ultimately, forcing this project to monetize in a way that isn't "open". You still can monetize with sponsorship, professional consulting, and other methods like cloud hosting platforms but I feel like that should be something you can do "for" the community not in spite of it.

I am also really excited about Bun and the current intentions of the project ecosystem based on what I've heard and some preliminary testing. But the reality is they have about 10+ yrs of bias towards node.js and big corporations (which adopt changes very slowly) have already committed with large code-bases. I think Bun needs big corp blessings to get swaps in critical mass for it to really take off and usurp nodejs. But, again unless they drop the VC somehow I'm not sure this would really happen in a productive way that benefits the community at large.

but i'm no fortune teller so who knows 🤷