[kotlin2]

But all else equal, wouldn’t you want the fastest option available? Also, it’s not just about raw qps. When a client connects to your app, you want them to receive data as quickly as possible so that they get the best user experience. That’s true wether you have 1 qps or 100,000. Having a development philosophy that every part of the stack must run quickly is attractive.

[moffkalast]

> all else equal

All else is never equal. The level of adoption and support is what drives decisions in the end. That's why everyone still uses Node when Bun is probably better in every way.

[jsf01]

>use bun

>segfault at runtime

Bun is far from better in every way

[hinkley]

Also I shouldn’t have to say this but all of the current JavaScript applications have already been written. Switching a large production codebase to a new framework does not dovetail well with modern dev practices, amplifying the pain of doing so.

[0xCAP]

I don't think application developers are the main target for their product. OTOH, if AWS/GCP/ETC. adopted Bun transparently to run your cloud functions faster and using less resources (thus less $$) that would be a win/win situation for all parties involved.

[Jenk]

> But all else equal

This is the point GP is making - they (the "junior-wannabe-senior") aren't even thinking of all else, and by focussing purely on the speed of operations are probably using the lesser optimal solution. Facetious example: A is faster than B, shaving a few cycles here and there. But nobody knows how to use A, it's support is lacklustre, and there are many known vulnerabilities that haven't been fixed. B is the most widely used in the industry, support and security is good. Junior-wannabe-senior is picking A because it's faster.

[thinkingkong]

Its tempting to assume that just because this number is high, that the rest of the dependencies required to meaningfully respond will be equally performant. That is rarely the case.

The challenge I have with these positions is that unless you have very specific latency requirements, most of the time youre better off focusing on solving a business problem and then measuring what is slow. Starting off with “well it has to be fast so lets use this brand new thing” is the swan song of the eventually remorseful.

[kotlin2]

Bun has a philosophy that everything needs to be fast. Including things like CLI tools and process startup. Process startup being quick is important, especially in a severless environment. I understand your point, but it’d be nice to limit the discussion to Bun and Deno and not other theoretical possibilities.

[hinkley]

I appreciate that Bun wants to be fast, but what I need right now from Bun or Deno is a better concurrency primitive than sendMessage(). I’m so… angry that we waited all this time for a worker threads implementation in Node and what we got was this hot garbage. It’s a toy. There is no sane way to send multiple tasks to the same worker, because the results come back unordered and uncorrelated, unless you build your own layer on top of them. The public API should have been promise based, not event based.

[liuliu]

Agreed. But the problem is not on "fast" but on "brand new". Sometimes, these are equal (because new things often advertising itself as fast alternative). Rare times when this is not equal, fast can be a good choice.

[netheril96]

But if the problem is in the framework or the runtime, it is too late to think about the performance AFTER you have tied yourself all up to the slower one.

[dmix]

These sorts of things also build up over time. Usually when the underlying system is well thought out and performant it’s reflected in higher layers as well.