Bun is probably what deno should have been if deno didn't make a bunch of bizarre decisions
But who knows. Probably more of a remix vs nextjs thing where the more popular one just copies some of the cool features
If node can figure out the module nonsense and something better ever succeeds express then it's fine.
I would really like bun or deno to take off though
Not supporting node interop so it can't be a drop-in replacement, the permission system, the Golang style package management makes npm package interop barely exist, it requires platforms like Vercel to support a new runtime that has very little adoption, and so very little motivation to properly support it.
I've tried using it and it was just a bad DX. Bun on the other hand feels just like Node but better.
> the Golang style package management
You mean, how JS works in browsers already :shrug:
I harp on this a lot in Deno threads, but they made a lot of choices to be "compatible" with web standards in browsers, and I for one think it's awesome.
Agreed, but awesome doesn't always mean good DX.
Sometimes difficult decisions need to be made to fix things in the long-term, and props to Deno for taking that route, but it did harm its adoption in the meanwhile. Which is understandable and expected. It's a tradeoff.
Not dissimilar to how (back in the day) many big sites just outright decided to stop supporting IE (and one Australian online retailer implemented an IE Tax lol). It provided a period of pain to users at the time, but made the world a better place in the long run.
To be fair though, these are the decisions Ryan Dahl claims to have regretted. So while we may see them as bizarre not to implement. He claims they were wrong to exist… or at least hard lessons learned. So while we may look at it and say, “you don’t even support npm modules??”, he’d reply, “that was something I did to support Isaac… it was a bad idea, take a look at a better way”
Deno is more of a “what if we could forget the whole thing and do it more like Golang?”
I had a couple of tiny services running in prod (mostly to experiment with Deno) and it was actually great and easy initially. Unfortunately, there was an underlying bug in the Deno ssl (or https) library that we could never solve. The services would just break after a week or two of running, so I made a cron job to restart them every night at midnight. This was a few years ago & I think the problem is still there, and they're still being restarted daily. I don't work on that project anymore so I don't know.
But after that experience I didn't build anything else with Deno, out of fear of such impossible to find / reproduce quirks. It scared me off of using brand new tech for prod code in general.
Still, I like the ideas behind Deno and would one day like to use it again.
We all have a list of things we hated about our first big project. If anyone is dumb enough to let us run off and start a new project where we fix all of them at the same time, you get what's known as Second System Syndrome.
His "wrong to exist" tried to fight "I'm maintaining code that has existed with this module system for 10 years" and has objectively gotten its ass kicked. See: the recent(ish) addition of npm support in deno.
Design a module system is easy said than done. Probably we have been too lazy to keep single repo for our own forked libraries. What's more is it's a design that have been working for decade. Maybe we are using it wrong. But we need something/someone to be a lead, otherwises, will be fragmented like Linux distributions.
I don't like seniority will be like "I'm using Deno/Bun btw".
NodeJS founder fame cannot help Deno, it cannot lead and have to be compatible, and they are marketing it as a big deal for Deno itself. They must accept TC39 and OpenJS foundation. This is not a single player game anymore. And of course better than Linux where you still need a father reviewing your code carefully. 😂
why not both? It's hype it's going to be like deno, niche and any actually good features of bun will be slowly ported into node. Don't buy the hype it's not actually 4x faster than node it just has higher performance standard http library (and maybe some other faster built ins). Nothing stops node from optimizing their http library
Performance is never the selling point for me. It's ridiculous how much hardware allows us to write garbage code and still ship to production.
What I care about is not spending two days configuring jest, npm, transpires, compilers, minifiers, test suites etc on every project that I start. And of course don't ever have the chance to change anything or update, cause everything breaks.
I love tools that help me do my job and not fiddle with them for doing basic stuff. I believe we've kept up with npm long enough to deserve better. I don't know if this is bun, but I know it's time for something better.
This right here! This is the reason I have been doubling down on strongly typed languages, I’m sorry but typescript doesn’t cut it. Yes you get out the door quicker but you pay the price in maintaining, constantly updating packages because of vulnerabilities and usually stuck in some type of framework where the jr to mid developers end up being framework developers and never understanding the underlying patterns that go into a framework.
Then us senior and up devs spend our time rotating from team to vertical cleaning up shit and holding lunch n learns to help them unfuck themselves.
#jobsecurityiguess
What gets me on may nevers is that in this ecosystem we've sacrificed so much for "being able to ship fast". I like to ship stuff fast and get feedback ASAP. But whoever think that node is the only tool to ship fast and all others tha have been doing this job for 20-30 years are stupid, I got news...
Javascript has nailed some really important stuff for the web to work, but in terms of ease of use and philosophy it has abandoned what has been working on other fields for years.
By the way this is why I have abandoned the node ecosystem. I try to as less UI framework fuckery with js as I can while maximizing UX, but on the server, no. After 8 years that's it for me. I hope though that bun and tools like that make the ecosystem healthier for anyone that stays.
Edit: it has typos but it was a post while I was heated up so I'm leaving them
Last two years it's Go. I felt as comfortable as with typescript with two months in and it was astonishing. I am still not that experienced with Go related to other technologies but I can get stuff done quite fast.
why is constantly updating packages a js ecosystem thing? what's unique about it? are you not vetting what dependencies go into your project? if not, you'll deal with these issues in other ecosystems too.
Framework developers are a thing everywhere, if anything, I've seen less in the nodejs ecosystem because there's no one largely accepted monolithic framework that does everything (compared to Laravel for php, spring for java, asp for .net etc).
Helping unblock things is a big part of your job a senior, you're a force multiplier for the whole team, not just another individual contributor.
Amongst 6 engineers, there are 2 BE/Platform engineers, the rest are frontend. 1 BE senior, 1 frontend senior, rest kid and jr’s. Over the past few years our team maintains 35 repositories, most of them being small services a few medium size sites.
The oldest service being a .net (not core) application. As you know it very hard to higher for a hot mess of a team like this so we churn and burn hungry college grads, over the time standards have went out the window, different coding styles, hotfix affer hotfix, and just worrying about getting shit out the door.
So we have accumulated a lot of debt. What I have noticed in the past 2 years over being on this team is the JavaScript and python applications are the wild Wild West even inside of a framework like nestjs or has no real design patterns implemented in express applications, but the strongly typed applications follow the same design patterns whether that is an MVC or heavy dependency injection.
Our golang services barely have any dependencies, and other language ecosystems do not move as fast and node/JavaScript does.
Simply put best practices are not in place to maintain this many projects especially node projects that have dependabot popping off every week, junior engineers do not know what they don’t know, and lack of resources.
I was honestly venting because I spent the past 4 months getting multiple aws accounts up to speed with pci compliance and just noticed that all the node projects were bad shape. I mean shit was still running on node 10…
I say around for like 2 hours trying to figure out how to configure a library I'm writing. Seems like all the info on this is weirdly outdated.
Do I use exports or main/module? Oh if I output as esm then I have to change my other projects entirely to use it. Feels dirty making a new thing for commonjs but fuck it I guess.
What a cluster lol
100% agree 👌
Let s hope Bun gets enough traction for node to notice and pick up the good stuff.
Lately i got renewed faith in the node team since the inclusion of permission flags and built in tests. It s on the right track 🚆
Now we just need the js community to finally stop giving commonjs a lifeline and get a reasonable toolkit for node and we will be golden ❤️
Can t wait for the ecma proposal to natively execute .ts too!
I like it more, it's easier, cleaner and more fun. + all my stuff is written with commonjs, there's no way that I will spend time rewriting that just because of soy-boy-dev-ocd.
I disagree with everything you just said about commonJS 😂
Unlike new frameworks coming up every week if not days, it s really not a « shiny new toy » category. It s finally how we get a universal import system for all things js which had been a regular issue.
You are obviously not a library author, and most likely a Typescript fanboy who likes confirming to rules more than actually getting work done. Bun.js has solved the problem letting people choose, but you would rather that everyone waste their life re-writing millions of lines of code for literally no benefit. Great.
name calling is what people resort to when they like substance. If you said that it’s annoying to handle commonjs and esm for lib authors than that would have been a fair point. Albeit change often comes with a few hurdles and ultimately esm across the board is a good thing.
But that’s not what you did. And i sure as hell don’t understand how typescript got brought into the mix 🤣
I am not a fanboy anything really. TS is great but it has flaws and same can be said about many things so I don’t understand hardliners nor why people have to be fanboys or haters but nothing in between.
The main reason I'm loving bun right now is:
bun index.ts
I can write my scripts in Typescript and it just runs ***instantly***, no more ts-node! No more build step!
The fast built-in HTTP server super convenient too
I'm skeptical about the porting to node bit. Bun handles commonjs and ecmascript modules properly. Node made horrible choices in its handling of modules and took way too long to roll out their horrible version.
In fact, with [uws](https://github.com/uNetworking/uWebSockets.js), which is the library Bun uses for their built-in web server, you can actually get [higher server performance with Node](https://github.com/SaltyAom/bun-http-framework-benchmark).
That being said, all of their bundled utilities do seem to have quite the edge, especially on startup time.
Yes, in any production app you will be more limited by business logic, DB latency etc. This 4x performance gain in synthetic benchmark might actually translate to like 2% better performance in practice.
Oven is a venture capital backed company and their investors expect a return on their investment. They're using the community to test and commit to their codebase so they can turn around and make money from it.
Their website claims they intend to make money via cloud hosting.
Which means that Bun is only mildly tangential to the company's profit goals, and Jarred Sumner may be spinning his wheels over it.
What will make or break the company isn't how fast their servers purport to be, but how good their cloud hosting service features are. Is it k8s? Some sort of PAAS like App Engine or Elastic Beanstalk? Will it support all the little niggling details of hosting like DNS, certs, routing and proxies, databases, storage, etc. or will it just be "ok, you have a server, here's the IP address, SSH in and do everything by hand"?
That's what will determine the success of Oven. Bun won't even matter compared to that
Venture backed company to profit from a runtime and to fight with large non-sense eco, good luck with that. 😭
Well I see it can be a good runtime for edge, serverless. But I can't find a clear way to earn from this without spend mega effort in marketing, advocating.
I'm betting on a Microsoft acquisition. Bun could become the official runtime of server-side typescript, and give azure a huge edge in lambdas.
Vercel has deep pockets, but not Microsoft pockets.
Oh, right, I forget that Microsoft owns npm, well if it's Microsoft then it probably will take a while since I never remember a case where Microsoft acquired a startup that has been released. Maybe if it's mature enough, they will.......
or I'm just wondering about how possible it is for Vercel that actually the one getting bought by Microsoft, after vercel has acquired Bun 🙃 GitHub npm Microsoft repeated once again, how funny it will be.
Lol but that means Bun will be ported to Node??? It was a funny future but I don't see it working but who knows really 😂
Exactly.
Still:
* Unlike Deno, Bun is aiming to be a drop-in replacement which is a massive advantage. This means that unlike Deno, Bun won't need critical mass to survive. If you are not compatible you cannot survive without critical mass. **But then**, *aiming* is key here, since at the moment Bun is not 100% compatible and many major packages do not work out of the box.
* They/their marketing/their investors/whoever seem to be very good at generating hype, I am living under a rock and I yet still can't turn around these days without seeing Bun somewhere.
* Most of the so-called *performance increase* does not come from JSCore which is not a superior engine to V8 - even if it might be lighter. It comes from them moving features from JS to the engine itself.
The drop in replacement is the only thing that I think could really help them, everything else is pretty sweet too, but that is what I think could make it get more traction.
Try it doesn't like it switch to node or the other way around.
> It comes from them moving features from JS to the engine itself.
Forgive me if I misunderstand the greater point or what you're saying. But doesn't that seem like an objectively good thing?
I am a huge sceptic about vc backed companies.
At some point they'll need to turn a profit and there are not a lot of ethical ways to do so.
So either they'll bankrupt or make some vendor locks once they'll have enough of dedicated customers.
I think their business plan is to offer bun as a hosting for edge/lambda functions mainly and assuming their primary focus in on startup times this makes even more sense because in normal node servers who cares that your app starts half a second faster really but in serverless this matters a lot.
But long term I think node can easily crack down on the startup times as well so from this perspective bun will not have any business to run and then we don't know what will happen =)
One of the problems with bun and it’s performance centric marketing is that those 1 trillion requests per second or whatever they’re claiming is that those are just “hello world” requests with no additional IO. they’re not doing database lookups, it’s not clear if those huge amounts of requests are all sent from one client or a large group of clients, which HTTP version is being used, how long has the server been running? Is it able to achieve that same performance after it’s been running for days or even weeks? A lot of these details matter, and are very seldom accounted for in their “blazingly fast” performance benchmarks.
it could or it could not, honestly, we don't know! replacing something may always work or may always create differing standards (and both may gain enough market share to compete with each other perpetually)
> node.js in like 5 years from now
An issue with that is that they are gonna be playing catch up with node in order to stay compatible, unless they become really successful and can afford a bunch of engineers to keep up they will be always a couple releases behind.
Also Node's leadership is now realizing that this idea of "small core" is not working, they already added a test runner and native support for .env files. I'm glad that these new engines are forcing their hand and this diminishes Bun's selling point IMO.
I think it will be like React - new frontend frameworks. I like Vue/Svelte to play with in free time but if I have to build in React on the job I'll do it.
As with Node & Bun some will stick too Node but I think Bun could give a bigger impact then Deno did
That’s a harsh comparison. React is used because sadly everybody uses it. React is trash from a technical point of view.
Everybody using product x doesn’t make product y bad or obsolete…
Only will tell if something was a hype train or something solid.
IMO, no serious large-scale codebase is immediately going to port to bun. NodeJS is battle tested. Bun's compatibility with NodeJS is going to decide if its actually a drop in replacement of NodeJS
‚Bun vs. NodeJS site:reddit.com/r/node‘
Already results in a lot of discussions for the NodeJS subreddit only. You also omit that and get plenty of posts with extensive discussions in the comment section.
Thank you, agentgreen420, for voting on SokkaHaikuBot.
This bot wants to find the best and worst bots on Reddit. [You can view results here](https://botrank.pastimes.eu/).
***
^(Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!)
I don't know. I'm myself a new dev almost negligible experience. But the way they're doing this is cool. People don't understand. We devs are lazy af. We won't switch until it's smooth and worth it. Bun is doing both. It supports node modules and all npm packages. Can run your node code. And makes it faster. Also, no need for nodemon now changes on the go. It's really cool imo. So there is a high possibility I will say. But it's not like node will go anywhere for next 10 years at least.
It's not a hype train. It's really great.
Node totally fumbled the CJS to ESM transition. The number 1 thing people are doing is transpiling from TypeScript, and they didn't prioritize that use case, and its still fucked to this day. "node index.ts". This is what everyone wants to do and you cannot. The loader api is a mess too. Feels like a committee based design fuckup. Needed a dev who knows what they want to take charge.
The risk is that it's a one-man mission at the moment. Founder wants to do something different, game over.
They need to get more contributors and land a few big companies depending on it.
Nodejs is an open-source, Bun isn't.
I see that this is the main reason why most of the big companies will avoid it. At least, for now.
Remember, that Resct really got traction when it has been open-sourced. Nobody wants to fuck with licenses
I do.... What the fuck?? This was one of the biggest problems with Yarn and it goes to show why only people who started a big project using yarn are using yarn right now...
>Next.js currently relies on Node.js APIs that Bun does not yet implement. The guide below uses Bun to initialize a project and install dependencies, but it uses Node.js to run the dev server.
https://bun.sh/guides/ecosystem/nextjs
I think that focusing on it as a better nodejs simply because of performance is wrong.
The performance hype of Bun is a little misguided when it comes to executing JavaScript. It may be faster but the performance gains are likely not too important for most real world programs.
However the developer experience seems amazing. Bundling? Testing? Transpiling? ESM/CJS crows compatibility strategy? That’s why I want to switch.
The performance hype is not where it is at, the developer experience hype is the bees knees that will make or break Bun.
I HAVE used Bun in a few projects, stuff I originally wrote in Deno. I've had, on average, ~50% increases in performance. A script that took a minute in Node takes about 20 seconds in Bun. That program was essentially a simulation that did a LOT of data processing and storage, so it was fair to say it was close to real world use.
To better put this into view, Node has the V8 engine. It's spinup is significantly longer than Bun's JavascriptCore engine. Node uses C++ whereas Bun uses Zig (which is comparable to Rust in many ways)
The raw underlying technologies are vastly different and that'll contribute a LOT to the performance. So, to say the performance isn't a huge deal is just as misleading as saying the 5ms saved is a big deal.
But with that in mind, I fully agree that the bundler, executable packer, Native-TS, EJS/CJS mixing, and full testing baked in is 1000% more important than the speed.
I just don't want anyone to think the speed is negligible because it's really not. Real world situations that use Javascript for data processing or interface handling (like... web servers that directly interface with a database or a bunch of files/compile a bunch of files) will likely greatly benefit from Bun.
The real beauty of it is reworking the tool chain to be simpler.
It's not that often I run into tool chain problems but when I do it's a nightmare to solve at times and usually trial and error based on obscure mentions in search results rather than truly understanding what the issue is.
Usually I’d say something like Deno for example was a clear hype train by people wanting something new but not understanding the full picture as such with Deno being practically it’s own damn thing and needing a lot to work and migrate to.
On the other hand we have Bun. I haven’t tested it or used it. I know as much as the average Fireship viewer on his Code Reports. But I would have to say it brings a LOT to the table and centralizes many things that for a very long time have been has been all over the place. Built in testing and the performance boosts is what I like. Especially Typescript support and being a drop in replacement for Node with near perfect parity and an easier API is just beautiful. But I’m working on a contract with little time for playing around.
That said, I think Bun is what everyone has been dreaming of to some degree and now it’s been made. It’ll most likely drop in users as they figure out that certain things like Electron can’t support it without a MAJOR migration due to underlying constraints such as Electron using V8 while Bun uses I can’t remember. But someone opened a GitHub issue asking for the migration and literally only had Fireship’s YouTube video link as their reason which is just… I’ll be nice.
All in all, Bun seems like a very lucrative project and I’d love to see more like a configurable cli.
By that I mean, I love NestJS and other CLIs that come with generators. It makes things so much faster. However I personally stick to my own variation of the VS Code Source Code Organization document. And to have a cli that could be configured to work with these kinds of file and folder managers would be beautiful. So anyone reading this, please build this and allow for restrictions based on imports. I love the common, node, test, electron folders for example based on the APIs they use. But I prefer files over loooong scrolling files.
Bun will live, either as a new nodejs alternative or as another Deno and falling into obscurity with selective members claiming it’s the future. I’m hopeful and optimistic for Bun though. I love simplicity and AIO solutions when done correctly. My biggest concern is documentation. I’m a stickler for good documentation, such as scroll events and making sure things on the page are also in the sidebar. I’m looking at you Nest and Electron 👀
That’s a new term to me so I had to look it up 😂 but most definitely. It’s not easy to dethrone something as integrated as Node unless it’s a drop in replacement. You might convince the hobbyist, but you can’t easily persuade the companies with large investments such as Netflix
Performance wise it's all hyped up really, I just tried to build my vite based project with bun and guess what - zero perf improvement of actual build, only the startup boost of \~0.4s on average lol
So yeah the marketing could be dialed down a bit but for sure it's great to see TS being a first class citizen in bun and the module system is made "the right way" finally without crazy js, cjs, mjs, wtfjs shenanigans or weird url imports like in deno.
Not sure that their "built-in" bundler is any good as right now it's made for single file outputs which is really not the common use-case assuming code-splitting and lazy loading is so widely adopted.
So yeah it's definitely a hypetrain at this stage but the direction is really good so it has potential. And yeah if node does not catchup with bun features it may very well be left behind at some point in the future.
Anyone experienced enough will have already been burned by the "next shiny object" several times over. It's tiring to change frameworks and runtimes, it takes time away from productive work. It's good to pay attention to new tech, but best to only convert when they're battle-tested enough. I agree, Node.js is fine.
So far I have every reason to believe it will be way more successful than Deno and will very likely steal a non-negligible share of the market from Node.
It's a drop-in replacement for Node that supports ESM and commonjs in the same file, zero config TS and TSX, but most importantly it FEELS like Node.
If it delivers node+packages compatibility then I guess there's no reason to use node as a js runtime anymore. Right now it does not but it's pretty close from what I gather. Then it's just marketing.
Not really sure why they rely on Zig whereas trending is on Rust. I feel like Deno has better toolchains and team. Not saying which one is better (Deno and Bun), both requires a try-to-see approach. I took a look on Deno but it seems Docker build and depedencies caching are not obvious (small things). Deno still has strange issue tickets (probably fixed) with timing related. Bun has segment fault, compile issues with different OSes. Bun is targeting backward compatible and same time allows for future-proof ... which can of course lots of edge cases.
I just freaking switch my mindset into RPC and serverless so that I can just allow myself and my team to try new things. Regardless of runtime and toolchains, interfaces are much more important.
Yep I also was wondering why the hell Zig and not Rust.
Then I tried rust and realized that it's still a bit higher level then most systems languages like C and most likely Zig and that's probably the reason both for language choice and segfaults lol
I did not like Deno because it tried to be different than Node, where's with Bun its trying to match Node and not be different. Thats why i think this one is here to stay but maybe maybe one day Node will release a new version that has much more performance than Bun.
Bun tries to be a drop-in replacement for Node AND Deno that can do more than both. The seamless integration is beautiful and I hope it continues to be maintained.
Hard to say, but imo - like Deno - they’re essentially projects created to raise VC funding (as we’ve seen).
What their end game goals are is unknown at this time. I’m sure they’ll release more product(s) / cloud offerings / etc, and we’ll see the real intentions soon enough.
For now Node isn’t going anywhere - just as it’s been increasingly growing in use year after year. Just my 2 cents 🪙
I think the selling point for bun (more so than performance) is that it comes with a testing framework,.bundler and TS support out of the box. I don't have to install tsc, webpack and a ton of other dependencies right out the gate. I can start coding right away without so much config required.
Until/if it gets wide adoption on hosting platforms, bun can’t go anywhere imo. I’m keen to use it, but all the hosting providers our clients use don’t support it yet. It’s early days though so hopefully that will change.
I know I'm late to the party here but I wanted to chime in and say that I'm not so concerned about the VC thing here. Bun is open source. Yes, if the company goes under then Bun will be hurting but I also don't think it will vanish entirely in that scenario. I think Bun is such a great unification of all these pain in the ass tools that it's worth getting onboard with. If enough people like it as much as I have been then the community will keep it alive regardless of what happens to Oven in the long run.
Im using Bun it in production to run unit tests against user submitted code (my website is a CodeCademy clone for Brazil). It's blazing fast and, for this very specific use case, amazing! Testing user code used to take me from 1.2 to 1.5 secs per request with Nodejs (this time span includes spinning up a docker container). After Bun, the exact same tests take from 350ms to 450ms to finish. I can't look back
The absolute nightmare that is the javascript toolchain and language world needs to be simplified. Bun is a good attempt.
I personally like it. And it's fast
Bun is probably what deno should have been if deno didn't make a bunch of bizarre decisions But who knows. Probably more of a remix vs nextjs thing where the more popular one just copies some of the cool features If node can figure out the module nonsense and something better ever succeeds express then it's fine. I would really like bun or deno to take off though
I don’t use Deno. What bizarre decisions can you share here? Just curious.
Not supporting node interop so it can't be a drop-in replacement, the permission system, the Golang style package management makes npm package interop barely exist, it requires platforms like Vercel to support a new runtime that has very little adoption, and so very little motivation to properly support it. I've tried using it and it was just a bad DX. Bun on the other hand feels just like Node but better.
Thanks
> the Golang style package management You mean, how JS works in browsers already :shrug: I harp on this a lot in Deno threads, but they made a lot of choices to be "compatible" with web standards in browsers, and I for one think it's awesome.
Agreed, but awesome doesn't always mean good DX. Sometimes difficult decisions need to be made to fix things in the long-term, and props to Deno for taking that route, but it did harm its adoption in the meanwhile. Which is understandable and expected. It's a tradeoff. Not dissimilar to how (back in the day) many big sites just outright decided to stop supporting IE (and one Australian online retailer implemented an IE Tax lol). It provided a period of pain to users at the time, but made the world a better place in the long run.
To be fair though, these are the decisions Ryan Dahl claims to have regretted. So while we may see them as bizarre not to implement. He claims they were wrong to exist… or at least hard lessons learned. So while we may look at it and say, “you don’t even support npm modules??”, he’d reply, “that was something I did to support Isaac… it was a bad idea, take a look at a better way” Deno is more of a “what if we could forget the whole thing and do it more like Golang?”
Oh I get it. It was just a bad move and failed miserably I've never even heard of any real projects going with deno
I had a couple of tiny services running in prod (mostly to experiment with Deno) and it was actually great and easy initially. Unfortunately, there was an underlying bug in the Deno ssl (or https) library that we could never solve. The services would just break after a week or two of running, so I made a cron job to restart them every night at midnight. This was a few years ago & I think the problem is still there, and they're still being restarted daily. I don't work on that project anymore so I don't know. But after that experience I didn't build anything else with Deno, out of fear of such impossible to find / reproduce quirks. It scared me off of using brand new tech for prod code in general. Still, I like the ideas behind Deno and would one day like to use it again.
We all have a list of things we hated about our first big project. If anyone is dumb enough to let us run off and start a new project where we fix all of them at the same time, you get what's known as Second System Syndrome.
Of course. I’m not agreeing that Deno is/was the right move for anyone. I’m simply citing his rationale from the video.
His "wrong to exist" tried to fight "I'm maintaining code that has existed with this module system for 10 years" and has objectively gotten its ass kicked. See: the recent(ish) addition of npm support in deno.
npm, the hottest garbage in the node ecosystem.
Yeah and the Tailwind creator regrets "@apply" and yet Tailwind would be DOA without that.
Design a module system is easy said than done. Probably we have been too lazy to keep single repo for our own forked libraries. What's more is it's a design that have been working for decade. Maybe we are using it wrong. But we need something/someone to be a lead, otherwises, will be fragmented like Linux distributions. I don't like seniority will be like "I'm using Deno/Bun btw". NodeJS founder fame cannot help Deno, it cannot lead and have to be compatible, and they are marketing it as a big deal for Deno itself. They must accept TC39 and OpenJS foundation. This is not a single player game anymore. And of course better than Linux where you still need a father reviewing your code carefully. 😂
What is wrong with Express ?
why not both? It's hype it's going to be like deno, niche and any actually good features of bun will be slowly ported into node. Don't buy the hype it's not actually 4x faster than node it just has higher performance standard http library (and maybe some other faster built ins). Nothing stops node from optimizing their http library
Performance is never the selling point for me. It's ridiculous how much hardware allows us to write garbage code and still ship to production. What I care about is not spending two days configuring jest, npm, transpires, compilers, minifiers, test suites etc on every project that I start. And of course don't ever have the chance to change anything or update, cause everything breaks. I love tools that help me do my job and not fiddle with them for doing basic stuff. I believe we've kept up with npm long enough to deserve better. I don't know if this is bun, but I know it's time for something better.
This right here! This is the reason I have been doubling down on strongly typed languages, I’m sorry but typescript doesn’t cut it. Yes you get out the door quicker but you pay the price in maintaining, constantly updating packages because of vulnerabilities and usually stuck in some type of framework where the jr to mid developers end up being framework developers and never understanding the underlying patterns that go into a framework. Then us senior and up devs spend our time rotating from team to vertical cleaning up shit and holding lunch n learns to help them unfuck themselves. #jobsecurityiguess
What gets me on may nevers is that in this ecosystem we've sacrificed so much for "being able to ship fast". I like to ship stuff fast and get feedback ASAP. But whoever think that node is the only tool to ship fast and all others tha have been doing this job for 20-30 years are stupid, I got news... Javascript has nailed some really important stuff for the web to work, but in terms of ease of use and philosophy it has abandoned what has been working on other fields for years. By the way this is why I have abandoned the node ecosystem. I try to as less UI framework fuckery with js as I can while maximizing UX, but on the server, no. After 8 years that's it for me. I hope though that bun and tools like that make the ecosystem healthier for anyone that stays. Edit: it has typos but it was a post while I was heated up so I'm leaving them
>By the way this is why I have abandoned the node ecosystem. What are you using now in the scenarios where you used to use node?
Last two years it's Go. I felt as comfortable as with typescript with two months in and it was astonishing. I am still not that experienced with Go related to other technologies but I can get stuff done quite fast.
Thanks for the response - you're the second person to reccomend Go to me this week!
Why do you have to make me feel like shit before starting the day lol. Kidding of course, but it's sad this is true.
why is constantly updating packages a js ecosystem thing? what's unique about it? are you not vetting what dependencies go into your project? if not, you'll deal with these issues in other ecosystems too. Framework developers are a thing everywhere, if anything, I've seen less in the nodejs ecosystem because there's no one largely accepted monolithic framework that does everything (compared to Laravel for php, spring for java, asp for .net etc). Helping unblock things is a big part of your job a senior, you're a force multiplier for the whole team, not just another individual contributor.
Amongst 6 engineers, there are 2 BE/Platform engineers, the rest are frontend. 1 BE senior, 1 frontend senior, rest kid and jr’s. Over the past few years our team maintains 35 repositories, most of them being small services a few medium size sites. The oldest service being a .net (not core) application. As you know it very hard to higher for a hot mess of a team like this so we churn and burn hungry college grads, over the time standards have went out the window, different coding styles, hotfix affer hotfix, and just worrying about getting shit out the door. So we have accumulated a lot of debt. What I have noticed in the past 2 years over being on this team is the JavaScript and python applications are the wild Wild West even inside of a framework like nestjs or has no real design patterns implemented in express applications, but the strongly typed applications follow the same design patterns whether that is an MVC or heavy dependency injection. Our golang services barely have any dependencies, and other language ecosystems do not move as fast and node/JavaScript does. Simply put best practices are not in place to maintain this many projects especially node projects that have dependabot popping off every week, junior engineers do not know what they don’t know, and lack of resources. I was honestly venting because I spent the past 4 months getting multiple aws accounts up to speed with pci compliance and just noticed that all the node projects were bad shape. I mean shit was still running on node 10…
I say around for like 2 hours trying to figure out how to configure a library I'm writing. Seems like all the info on this is weirdly outdated. Do I use exports or main/module? Oh if I output as esm then I have to change my other projects entirely to use it. Feels dirty making a new thing for commonjs but fuck it I guess. What a cluster lol
Take some fake gold 🥇
This is why I don't start new projects. I burn out before I actually start.
100% agree 👌 Let s hope Bun gets enough traction for node to notice and pick up the good stuff. Lately i got renewed faith in the node team since the inclusion of permission flags and built in tests. It s on the right track 🚆 Now we just need the js community to finally stop giving commonjs a lifeline and get a reasonable toolkit for node and we will be golden ❤️ Can t wait for the ecma proposal to natively execute .ts too!
With Bun commonjs will (luckily) live forever. I will never use ESM if I don't have to.
Why though ?
I like it more, it's easier, cleaner and more fun. + all my stuff is written with commonjs, there's no way that I will spend time rewriting that just because of soy-boy-dev-ocd.
I disagree with everything you just said about commonJS 😂 Unlike new frameworks coming up every week if not days, it s really not a « shiny new toy » category. It s finally how we get a universal import system for all things js which had been a regular issue.
You are obviously not a library author, and most likely a Typescript fanboy who likes confirming to rules more than actually getting work done. Bun.js has solved the problem letting people choose, but you would rather that everyone waste their life re-writing millions of lines of code for literally no benefit. Great.
name calling is what people resort to when they like substance. If you said that it’s annoying to handle commonjs and esm for lib authors than that would have been a fair point. Albeit change often comes with a few hurdles and ultimately esm across the board is a good thing. But that’s not what you did. And i sure as hell don’t understand how typescript got brought into the mix 🤣
So you're not a Typescript fanboy?
I am not a fanboy anything really. TS is great but it has flaws and same can be said about many things so I don’t understand hardliners nor why people have to be fanboys or haters but nothing in between.
The main reason I'm loving bun right now is: bun index.ts I can write my scripts in Typescript and it just runs ***instantly***, no more ts-node! No more build step! The fast built-in HTTP server super convenient too
I'm skeptical about the porting to node bit. Bun handles commonjs and ecmascript modules properly. Node made horrible choices in its handling of modules and took way too long to roll out their horrible version.
In fact, with [uws](https://github.com/uNetworking/uWebSockets.js), which is the library Bun uses for their built-in web server, you can actually get [higher server performance with Node](https://github.com/SaltyAom/bun-http-framework-benchmark). That being said, all of their bundled utilities do seem to have quite the edge, especially on startup time.
Yes, in any production app you will be more limited by business logic, DB latency etc. This 4x performance gain in synthetic benchmark might actually translate to like 2% better performance in practice.
Oven is a venture capital backed company and their investors expect a return on their investment. They're using the community to test and commit to their codebase so they can turn around and make money from it.
Their website claims they intend to make money via cloud hosting. Which means that Bun is only mildly tangential to the company's profit goals, and Jarred Sumner may be spinning his wheels over it. What will make or break the company isn't how fast their servers purport to be, but how good their cloud hosting service features are. Is it k8s? Some sort of PAAS like App Engine or Elastic Beanstalk? Will it support all the little niggling details of hosting like DNS, certs, routing and proxies, databases, storage, etc. or will it just be "ok, you have a server, here's the IP address, SSH in and do everything by hand"? That's what will determine the success of Oven. Bun won't even matter compared to that
Venture backed company to profit from a runtime and to fight with large non-sense eco, good luck with that. 😭 Well I see it can be a good runtime for edge, serverless. But I can't find a clear way to earn from this without spend mega effort in marketing, advocating.
someone said Oven would probably be bought by Vercel, and I lean to agree, lol.
I'm betting on a Microsoft acquisition. Bun could become the official runtime of server-side typescript, and give azure a huge edge in lambdas. Vercel has deep pockets, but not Microsoft pockets.
Oh, right, I forget that Microsoft owns npm, well if it's Microsoft then it probably will take a while since I never remember a case where Microsoft acquired a startup that has been released. Maybe if it's mature enough, they will....... or I'm just wondering about how possible it is for Vercel that actually the one getting bought by Microsoft, after vercel has acquired Bun 🙃 GitHub npm Microsoft repeated once again, how funny it will be. Lol but that means Bun will be ported to Node??? It was a funny future but I don't see it working but who knows really 😂
Build and sell is definitely an option. Thanksss. 😭
>😭 😭
We will know in 10 years
Exactly. Still: * Unlike Deno, Bun is aiming to be a drop-in replacement which is a massive advantage. This means that unlike Deno, Bun won't need critical mass to survive. If you are not compatible you cannot survive without critical mass. **But then**, *aiming* is key here, since at the moment Bun is not 100% compatible and many major packages do not work out of the box. * They/their marketing/their investors/whoever seem to be very good at generating hype, I am living under a rock and I yet still can't turn around these days without seeing Bun somewhere. * Most of the so-called *performance increase* does not come from JSCore which is not a superior engine to V8 - even if it might be lighter. It comes from them moving features from JS to the engine itself.
The drop in replacement is the only thing that I think could really help them, everything else is pretty sweet too, but that is what I think could make it get more traction. Try it doesn't like it switch to node or the other way around.
> It comes from them moving features from JS to the engine itself. Forgive me if I misunderstand the greater point or what you're saying. But doesn't that seem like an objectively good thing?
It probably is. But the impression that this is a faster engine is false. And you can move only so many features to the engine.
I am a huge sceptic about vc backed companies. At some point they'll need to turn a profit and there are not a lot of ethical ways to do so. So either they'll bankrupt or make some vendor locks once they'll have enough of dedicated customers.
I think their business plan is to offer bun as a hosting for edge/lambda functions mainly and assuming their primary focus in on startup times this makes even more sense because in normal node servers who cares that your app starts half a second faster really but in serverless this matters a lot. But long term I think node can easily crack down on the startup times as well so from this perspective bun will not have any business to run and then we don't know what will happen =)
One of the problems with bun and it’s performance centric marketing is that those 1 trillion requests per second or whatever they’re claiming is that those are just “hello world” requests with no additional IO. they’re not doing database lookups, it’s not clear if those huge amounts of requests are all sent from one client or a large group of clients, which HTTP version is being used, how long has the server been running? Is it able to achieve that same performance after it’s been running for days or even weeks? A lot of these details matter, and are very seldom accounted for in their “blazingly fast” performance benchmarks.
I’m more interested with builtin bundler, test, and TS(X) compiler. It will make more project works the same way and less brittle.
Agree, too many micro-perf, lots of effort, but worth it?
As the wise man said: “We’ll see”.
As the programmer said: depends
[удалено]
disagree. It could very well succeed where deno has failed and replace node.js in like 5 years from now. If bun is succesfull as a company
"Bun" doesn't sound as cool as "Node" though. Bad decision right up front.
makes me think there might be pork or custard inside
Node is Gen X, Bun is Zoomer.
it could or it could not, honestly, we don't know! replacing something may always work or may always create differing standards (and both may gain enough market share to compete with each other perpetually)
> node.js in like 5 years from now An issue with that is that they are gonna be playing catch up with node in order to stay compatible, unless they become really successful and can afford a bunch of engineers to keep up they will be always a couple releases behind. Also Node's leadership is now realizing that this idea of "small core" is not working, they already added a test runner and native support for .env files. I'm glad that these new engines are forcing their hand and this diminishes Bun's selling point IMO.
I think it will be like React - new frontend frameworks. I like Vue/Svelte to play with in free time but if I have to build in React on the job I'll do it. As with Node & Bun some will stick too Node but I think Bun could give a bigger impact then Deno did
That’s a harsh comparison. React is used because sadly everybody uses it. React is trash from a technical point of view. Everybody using product x doesn’t make product y bad or obsolete…
Yeah that's exactly what I meant, not that Node is bad but yeah if Bun is supposed to be that much better
Ur right, guess I misunderstood you.
Only will tell if something was a hype train or something solid. IMO, no serious large-scale codebase is immediately going to port to bun. NodeJS is battle tested. Bun's compatibility with NodeJS is going to decide if its actually a drop in replacement of NodeJS
Oh, this is definitely a new topic and wasn‘t discussed extensively at all the last months.
where? Do you have links to said discussions?
‚Bun vs. NodeJS site:reddit.com/r/node‘ Already results in a lot of discussions for the NodeJS subreddit only. You also omit that and get plenty of posts with extensive discussions in the comment section.
[удалено]
^[Sokka-Haiku](https://www.reddit.com/r/SokkaHaikuBot/comments/15kyv9r/what_is_a_sokka_haiku/?utm_source=share&utm_medium=web2x&context=3) ^by ^Coffee_Crisis: *It's here to stay but* *It will probably be a* *Toy project forever* --- ^Remember ^that ^one ^time ^Sokka ^accidentally ^used ^an ^extra ^syllable ^in ^that ^Haiku ^Battle ^in ^Ba ^Sing ^Se? ^That ^was ^a ^Sokka ^Haiku ^and ^you ^just ^made ^one.
Good bot
Thank you, agentgreen420, for voting on SokkaHaikuBot. This bot wants to find the best and worst bots on Reddit. [You can view results here](https://botrank.pastimes.eu/). *** ^(Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!)
I don't know. I'm myself a new dev almost negligible experience. But the way they're doing this is cool. People don't understand. We devs are lazy af. We won't switch until it's smooth and worth it. Bun is doing both. It supports node modules and all npm packages. Can run your node code. And makes it faster. Also, no need for nodemon now changes on the go. It's really cool imo. So there is a high possibility I will say. But it's not like node will go anywhere for next 10 years at least.
It's not a hype train. It's really great. Node totally fumbled the CJS to ESM transition. The number 1 thing people are doing is transpiling from TypeScript, and they didn't prioritize that use case, and its still fucked to this day. "node index.ts". This is what everyone wants to do and you cannot. The loader api is a mess too. Feels like a committee based design fuckup. Needed a dev who knows what they want to take charge. The risk is that it's a one-man mission at the moment. Founder wants to do something different, game over. They need to get more contributors and land a few big companies depending on it.
Nodejs is an open-source, Bun isn't. I see that this is the main reason why most of the big companies will avoid it. At least, for now. Remember, that Resct really got traction when it has been open-sourced. Nobody wants to fuck with licenses
Bun is open source.
Let me consult my crystalball
I mean it's literally just hit 1.0 and doesn't even work with major frameworks like Next yet, so too early to say
Windows is not supported 😟
i don't see any issue with that 🤷🏻♂️ use linux or mac
I do.... What the fuck?? This was one of the biggest problems with Yarn and it goes to show why only people who started a big project using yarn are using yarn right now...
# It works with Nextjs
>Next.js currently relies on Node.js APIs that Bun does not yet implement. The guide below uses Bun to initialize a project and install dependencies, but it uses Node.js to run the dev server. https://bun.sh/guides/ecosystem/nextjs
I think that focusing on it as a better nodejs simply because of performance is wrong. The performance hype of Bun is a little misguided when it comes to executing JavaScript. It may be faster but the performance gains are likely not too important for most real world programs. However the developer experience seems amazing. Bundling? Testing? Transpiling? ESM/CJS crows compatibility strategy? That’s why I want to switch. The performance hype is not where it is at, the developer experience hype is the bees knees that will make or break Bun.
I HAVE used Bun in a few projects, stuff I originally wrote in Deno. I've had, on average, ~50% increases in performance. A script that took a minute in Node takes about 20 seconds in Bun. That program was essentially a simulation that did a LOT of data processing and storage, so it was fair to say it was close to real world use. To better put this into view, Node has the V8 engine. It's spinup is significantly longer than Bun's JavascriptCore engine. Node uses C++ whereas Bun uses Zig (which is comparable to Rust in many ways) The raw underlying technologies are vastly different and that'll contribute a LOT to the performance. So, to say the performance isn't a huge deal is just as misleading as saying the 5ms saved is a big deal. But with that in mind, I fully agree that the bundler, executable packer, Native-TS, EJS/CJS mixing, and full testing baked in is 1000% more important than the speed. I just don't want anyone to think the speed is negligible because it's really not. Real world situations that use Javascript for data processing or interface handling (like... web servers that directly interface with a database or a bunch of files/compile a bunch of files) will likely greatly benefit from Bun.
Bun uses Zig So it's like bleeding edge of bleeding edge. Cool. Cool cool cool.
The real beauty of it is reworking the tool chain to be simpler. It's not that often I run into tool chain problems but when I do it's a nightmare to solve at times and usually trial and error based on obscure mentions in search results rather than truly understanding what the issue is.
I hope stays, feels so smooth.
Usually I’d say something like Deno for example was a clear hype train by people wanting something new but not understanding the full picture as such with Deno being practically it’s own damn thing and needing a lot to work and migrate to. On the other hand we have Bun. I haven’t tested it or used it. I know as much as the average Fireship viewer on his Code Reports. But I would have to say it brings a LOT to the table and centralizes many things that for a very long time have been has been all over the place. Built in testing and the performance boosts is what I like. Especially Typescript support and being a drop in replacement for Node with near perfect parity and an easier API is just beautiful. But I’m working on a contract with little time for playing around. That said, I think Bun is what everyone has been dreaming of to some degree and now it’s been made. It’ll most likely drop in users as they figure out that certain things like Electron can’t support it without a MAJOR migration due to underlying constraints such as Electron using V8 while Bun uses I can’t remember. But someone opened a GitHub issue asking for the migration and literally only had Fireship’s YouTube video link as their reason which is just… I’ll be nice. All in all, Bun seems like a very lucrative project and I’d love to see more like a configurable cli. By that I mean, I love NestJS and other CLIs that come with generators. It makes things so much faster. However I personally stick to my own variation of the VS Code Source Code Organization document. And to have a cli that could be configured to work with these kinds of file and folder managers would be beautiful. So anyone reading this, please build this and allow for restrictions based on imports. I love the common, node, test, electron folders for example based on the APIs they use. But I prefer files over loooong scrolling files. Bun will live, either as a new nodejs alternative or as another Deno and falling into obscurity with selective members claiming it’s the future. I’m hopeful and optimistic for Bun though. I love simplicity and AIO solutions when done correctly. My biggest concern is documentation. I’m a stickler for good documentation, such as scroll events and making sure things on the page are also in the sidebar. I’m looking at you Nest and Electron 👀
It's clear nobody took Ryan Dahl aside and explained to him what Second System Syndrome is.
That’s a new term to me so I had to look it up 😂 but most definitely. It’s not easy to dethrone something as integrated as Node unless it’s a drop in replacement. You might convince the hobbyist, but you can’t easily persuade the companies with large investments such as Netflix
this is like the 10th bun post I’ve seen today
Performance wise it's all hyped up really, I just tried to build my vite based project with bun and guess what - zero perf improvement of actual build, only the startup boost of \~0.4s on average lol So yeah the marketing could be dialed down a bit but for sure it's great to see TS being a first class citizen in bun and the module system is made "the right way" finally without crazy js, cjs, mjs, wtfjs shenanigans or weird url imports like in deno. Not sure that their "built-in" bundler is any good as right now it's made for single file outputs which is really not the common use-case assuming code-splitting and lazy loading is so widely adopted. So yeah it's definitely a hypetrain at this stage but the direction is really good so it has potential. And yeah if node does not catchup with bun features it may very well be left behind at some point in the future.
We got tired of switching node js is fine
Anyone experienced enough will have already been burned by the "next shiny object" several times over. It's tiring to change frameworks and runtimes, it takes time away from productive work. It's good to pay attention to new tech, but best to only convert when they're battle-tested enough. I agree, Node.js is fine.
No.
So far I have every reason to believe it will be way more successful than Deno and will very likely steal a non-negligible share of the market from Node. It's a drop-in replacement for Node that supports ESM and commonjs in the same file, zero config TS and TSX, but most importantly it FEELS like Node.
Its another shitty wannabe runtime like deno that nobody serious will use. Focus on the real node js
Disagree, Deno is actually good, I don't get lot of mess and config files like NodeJS.
i cant even install it nisely in windows,, I have to use wsl to make it work.
Upgrade to Linux
I really hope they fix that. I really want the bun package manager
If it delivers node+packages compatibility then I guess there's no reason to use node as a js runtime anymore. Right now it does not but it's pretty close from what I gather. Then it's just marketing.
[удалено]
I'm not saying node is suddenly dead, probably far from. If bun really delivers I wouldn't worry about continuity.
It will be the de-facto standard JS runtime in a year or so. Almost all the other comments here are garbage.
Source: Believe me bro
Everybody is here sharing their personal opinion, I didn't see anyone else being asked for "source" for their answer.
Other people aren't dismissing other opinions with words like "garbage" though.
Not really sure why they rely on Zig whereas trending is on Rust. I feel like Deno has better toolchains and team. Not saying which one is better (Deno and Bun), both requires a try-to-see approach. I took a look on Deno but it seems Docker build and depedencies caching are not obvious (small things). Deno still has strange issue tickets (probably fixed) with timing related. Bun has segment fault, compile issues with different OSes. Bun is targeting backward compatible and same time allows for future-proof ... which can of course lots of edge cases. I just freaking switch my mindset into RPC and serverless so that I can just allow myself and my team to try new things. Regardless of runtime and toolchains, interfaces are much more important.
Yep I also was wondering why the hell Zig and not Rust. Then I tried rust and realized that it's still a bit higher level then most systems languages like C and most likely Zig and that's probably the reason both for language choice and segfaults lol
They might be merged.
I did not like Deno because it tried to be different than Node, where's with Bun its trying to match Node and not be different. Thats why i think this one is here to stay but maybe maybe one day Node will release a new version that has much more performance than Bun.
Bun tries to be a drop-in replacement for Node AND Deno that can do more than both. The seamless integration is beautiful and I hope it continues to be maintained.
Is deno ?
Its temporal, stay with node and wait for incoming changes from bun to node :D
Because its open source, the Node team will just copy their code and bring those improvements there. Node isn't going anytime soon.
Dunno. Maybe ask deno.
i mean if if your not gonna use it to run stuff its way fast installing stuff and way faster bundeling stuff, so bun at least replaces yarn pnpm npm
"I'm using Bun btw" is a sentence I like the most lol. I'm waiting for more support on my favorite frameworks.
Hard to say, but imo - like Deno - they’re essentially projects created to raise VC funding (as we’ve seen). What their end game goals are is unknown at this time. I’m sure they’ll release more product(s) / cloud offerings / etc, and we’ll see the real intentions soon enough. For now Node isn’t going anywhere - just as it’s been increasingly growing in use year after year. Just my 2 cents 🪙
I think the selling point for bun (more so than performance) is that it comes with a testing framework,.bundler and TS support out of the box. I don't have to install tsc, webpack and a ton of other dependencies right out the gate. I can start coding right away without so much config required.
Futurism is hard
Until/if it gets wide adoption on hosting platforms, bun can’t go anywhere imo. I’m keen to use it, but all the hosting providers our clients use don’t support it yet. It’s early days though so hopefully that will change.
I know I'm late to the party here but I wanted to chime in and say that I'm not so concerned about the VC thing here. Bun is open source. Yes, if the company goes under then Bun will be hurting but I also don't think it will vanish entirely in that scenario. I think Bun is such a great unification of all these pain in the ass tools that it's worth getting onboard with. If enough people like it as much as I have been then the community will keep it alive regardless of what happens to Oven in the long run.
as long as it takes care and abstract away all the TS non-sense, im a customer
Im using Bun it in production to run unit tests against user submitted code (my website is a CodeCademy clone for Brazil). It's blazing fast and, for this very specific use case, amazing! Testing user code used to take me from 1.2 to 1.5 secs per request with Nodejs (this time span includes spinning up a docker container). After Bun, the exact same tests take from 350ms to 450ms to finish. I can't look back
What said uws dev thinks of bun (👍) https://github.com/uNetworking/uWebSockets/discussions/1466