zlacker

I wonder what this means for Deno.

Will this make it more or less likely for people to use Bun vs Deno?

And now that Bun doesn't need to run a profitable cloud company will they move faster and get ahead of Deno?

>>pier25+(OP)
I think Deno's management have been somewhat distracted by their ongoing lawsuits with Oracle over the release of the Javascript trademark.

I started out with Deno and when I discovered Bun, I pivoted. Personally I don't need the NodeJS/NPM compatability. Wish there was a Bun-lite which was freed of the backward compatability.

>>GianFa+d5
I'm in a similar position.

I use Hono, Zod, and Drizzle which AFAIK don't need Node compat.

IIRC I've only used Node compat once to delete a folder recursively with rm.

>>GianFa+d5
What do you dislike about having node compatibility?

>>GianFa+d5
Ironically, this was early Deno - but then adoption required backwards compatibility.

>>pier25+(OP)
> Will this make it more or less likely for people to use Bun vs Deno?

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.

>>pier25+(OP)
Prediction Bun is absorbed in house and used by Anthropic to have faster/cheaper places for Claude to run code.

It fades away as a direct to developer tool.

This is a good thing for Deno.

>>pier25+(OP)
Bun and Deno's goals seem quite different, I don't expect that to change. Bun is a one stop shop with an ever increasing number of built-in high-level APIs. Deno is focused on low level APIs, security, and building out a standard lib/ecosystem that (mostly) supports all JS environments.

People who like Bun for what it is are probably still going to, and same goes for Deno.

That being said I don't see how Anthropic is really adding long term stability to Bun.

>>pier25+(OP)
Deno is dead. Seems like there haven't been very relevant or user-informed changes on their roadmap for year(s) now.

>>Zambyt+qv
The bloat. I prefer lean designs with plug-in modules for additional functionality. Not only do unused sub-systems take up memory, but they also increase the potential attack surface.

>>GianFa+d5
In regards to Deno, to me that means their business is not really flying and they need this kind of distractions instead.

Amount of people at big corps that care about their lawsuit, and would switch their IT guidelines from node to Deno due to such heroic efforts?

Zero.

>>sparta+6w
> Deno fixes both of those problems with a proper permission model and a standard library

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.

>>joshcs+5T
> Deno is dead.

Not yet; similar concerns were addressed by Dahl 6mo ago: https://deno.com/blog/greatly-exaggerated / https://archive.vn/L6His

>>pier25+q42
> Bun has a better standard library than Deno. You get a DB driver, S3 client, etc which on Deno are all third party deps.

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.