I'm not sure it will make much of a difference in the short term.
For those who were drawn to Bun by hype and/or some concerns around speed, they will continue to use Bun.
For me personally, I will continue to use Node for legacy projects and will continue using Deno for current projects.
I'm not interested in Bun for it's hype (since hype is fleeting). I have a reserved interested in Bun's approach to speed but I don't see it being a significant factor since most JS speed concerns come from downloading dependencies (which is a once-off operation) and terrible JS framework practices (which aren't resolved by changing engines anyway).
----------------------------
The two largest problems I see in JS are:
1. Terrible security practices
2. A lack of a standard library which pushes people into dependency hell
Deno fixes both of those problems with a proper permission model and a standard library.
----------------------------
> And now that Bun doesn't need to run a profitable cloud company will they move faster and get ahead of Deno?
I think any predictions between 1-10 years are going to be a little too chaotic. It all depends on how the AI bubble goes away.
But after 10 years, I can see runtimes switching from their current engines to one based on Boa, Kiesel or something similar.
Bun has a better standard library than Deno. You get a DB driver, S3 client, etc which on Deno are all third party deps. It was the main reason I got interested in Bun. The speed is nice though during dev. Everything feels instant.
Aren't you hosting Bun on a 3rd party host though?
Wouldn't you want to use the 3rd party's own dependency to connect to the 3rd party's services?
---
I wasn't sure how bun handled it's db driver so I just checked the docs. Looks like they try to have a single api for multiple databases by writing queries in template strings.
I can see the appeal of a single api, but using template strings looks like a bad way to do it.
What happens when someone adds a keyword or function into a query that exists in one database engine but not another? Or even in one version of a database but not another? Or even in the same database engine and same version but with different settings?
It's a terrible debugging experience trying to resolve those kinds of issues when you're depending on a database that someone else has set up.
You need a different driver for each database engine, or you can have a unified api if you use an ORM since it can translate or shim your query into the SQL supported by your database engine.