Ask HN: Using Bluebird Promises in 2025? | Hacker News Reader

Ask HN: Using Bluebird Promises in 2025?

1 pointawaitasyncplz3 comments

Halp, I am writing in desperation. My company's customer-facing API bits are written in nodejs, and our VP insists that we are not allowed to use async/await, and must instead use Bluebird promises [1].

The rationale is that native promises have different, and worse, performance characteristics... Which I think is maybe technically true. Something about the event loop and microticks.

And they've had to fix various latency issues over the years due to people using native promises instead of Bluebird in our codebase.

But our code is full of boilerplate, harder to read and maintain as a result and I'm struggling to accept that this is the right tradeoff for a growing team (~30 devs working on this codebase)

I also just can't believe that a lot of other shops are doing this, or that we're the only ones running into these performance issues.

Maybe it's our use-case? I kinda doubt it. We're an observability/analytics product so there's a fair bit of data transformation going on. But we don't have a ton of concurrent users (think dozens).

I'm hoping that this thread can attract some performance-conscious nodejs engineers who can help shed some light on how your apps aren't slow or blocking all the time despite using native promises.

Thanks, and Happy Friday!

The Bluebird devs themselves no longer recommend using it if you can help it:

> Please use native promises instead if at all possible. Native Promises have been stable in Node.js and browsers for around 10 years now and they have been fast for around 7. Any utility bluebird has like .map has native equivalents (like Node streams' .map).

> This is a good thing, the people working on Bluebird and promises have been able to help incorporate most of the useful things from Bluebird into JavaScript itself and platforms/engines.

> If there is a feature that keeps you using bluebird. Please let us know so we can try and upstream it :)

> Currently - it is only recommended to use Bluebird if you need to support really old browsers or EoL Node.js or as an intermediate step to use warnings/monitoring to find bugs.

> My company's customer-facing API bits are written in nodejs,

First mistake.

If the argument is about performance, then using nodejs is really a bad choice in general. Node promises are already expensive on memory and can easily cause memory leaks if not handled properly.

> and our VP insists that we are not allowed to use async/await, and must instead use Bluebird promises [1].

I don't think Bluebird will solve the problem and is more likely to break on new versions of node that have critical security fixes.

If you are seriously after performance with strong concurrency characteristics, use Go instead.

One approach you could use is to

- run your code through a preprocessor (like tsc or babel) and have it set to generate 'es2016' code. This will transpile out async/await to equivalent code without those keywords.

- Then edit the generated code and/or the runtime library it attaches to use Bluebird promises instead of native promises.

Are you on an old version of nodejs? Past a certain version (I don't know which one), native promises are actually faster.

Reply on news.ycombinator.com