The entire idea of calling it a "drop-in replacement" is ludicrous. It just isn't, if you're forcing me to change my imports. Perfect example: I have an npm module that's a wrapper around better-sqlite3. I've been developing it for years, it has 5+ million downloads, and it works great.
Someone opened an issue asking that I "add bun compatibility" which of course is idiotic : if Bun is a drop-in replacement, why the hell would I need to change anything? So when I said "no, let them be compatible, I have no intention of doing this sort of development effort" the person just forked my repo and made a bun-compatible version by switching the imports to bun:sqlite.
Now you might ask, why do I not feel like doing development effort here? Simply put, I'm on Windows, and I'm not about to install a different operating system (Virtualized or otherwise) just to make a supposed drop-in replacement actually work when dropped in. So... nah. No thanks, Bun. I'm good.
Thanks for this real-world anecdote. There are many other people in the comments claiming Windows support isn't worth Bun's time, but ultimately it will be the reason why they won't be able to overtake the much more mature, stable, and fully cross-platform alternatives.
I spend extra time making sure all of my libraries run the same on all platforms. Or include all platform specific options for those types of cases. I'm very proud of how most of the Node ecosystem has done the same. All platforms being treated equally.
Having been around for a long time, I find it especially funny how the Linux community used to complain in the 90's and 2000's about no one taking them seriously and supporting them. Now they are on the opposite end of that table and arguing against adding support for Windows. They didn't want all OS's to be treated equally, they just wanted stuff to work for them. Which is the same thing they complained about of other non-Linux users. Fascinating, and sad.
I foresee a lot of libraries getting if (bun) {} else {} added to them. I don't think that's a terrible thing, in general, it's much better than the alternative of only supporting Bun. However, like with any project, the larger it gets, the more effort will be required in maintaining this additional feature (Bun support). And at some point, when Bun starts to die off, they'll need to do a major bump release to convey deprecating support for Bun. It's a choice people can make, to offer additional support in the short term and opt-in to future tech-debt.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The entire idea of calling it a "drop-in replacement" is ludicrous. It just isn't, if you're forcing me to change my imports. Perfect example: I have an npm module that's a wrapper around better-sqlite3. I've been developing it for years, it has 5+ million downloads, and it works great.
Someone opened an issue asking that I "add bun compatibility" which of course is idiotic : if Bun is a drop-in replacement, why the hell would I need to change anything? So when I said "no, let them be compatible, I have no intention of doing this sort of development effort" the person just forked my repo and made a bun-compatible version by switching the imports to bun:sqlite.
Now you might ask, why do I not feel like doing development effort here? Simply put, I'm on Windows, and I'm not about to install a different operating system (Virtualized or otherwise) just to make a supposed drop-in replacement actually work when dropped in. So... nah. No thanks, Bun. I'm good.
Thanks for this real-world anecdote. There are many other people in the comments claiming Windows support isn't worth Bun's time, but ultimately it will be the reason why they won't be able to overtake the much more mature, stable, and fully cross-platform alternatives.
I spend extra time making sure all of my libraries run the same on all platforms. Or include all platform specific options for those types of cases. I'm very proud of how most of the Node ecosystem has done the same. All platforms being treated equally.
Having been around for a long time, I find it especially funny how the Linux community used to complain in the 90's and 2000's about no one taking them seriously and supporting them. Now they are on the opposite end of that table and arguing against adding support for Windows. They didn't want all OS's to be treated equally, they just wanted stuff to work for them. Which is the same thing they complained about of other non-Linux users. Fascinating, and sad.
I foresee a lot of libraries getting
if (bun) {} else {}added to them. I don't think that's a terrible thing, in general, it's much better than the alternative of only supporting Bun. However, like with any project, the larger it gets, the more effort will be required in maintaining this additional feature (Bun support). And at some point, when Bun starts to die off, they'll need to do a major bump release to convey deprecating support for Bun. It's a choice people can make, to offer additional support in the short term and opt-in to future tech-debt.