Rendered at 13:28:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dan_rock_wilson 22 hours ago [-]
Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support.
I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?
Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.
vmg12 21 hours ago [-]
Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.
A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).
So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.
I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.
Edit: And Deno is now more compatible with node than bun.
gslepak 20 hours ago [-]
> In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things
"Probably"? Are you saying there's a chance he wasn't right?
I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.
MrJohz 16 hours ago [-]
I think the biggest issue with Deno is that it fixes real issues but in the wrong way.
Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.
The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.
It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.
This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.
lenkite 4 hours ago [-]
Are there languages and runtimes which have done stuff at this low-level before ? Sandboxing at the individual function level ?
stephbook 4 hours ago [-]
Use a .devcontainer and you're done in 10 seconds without any new runtime implementations.
sysguest 18 hours ago [-]
this
we nodejs devs were just ignorant/lazy
npmjs should mark libs "deno compatible" and move over to deno gradually for security
VerifiedReports 20 hours ago [-]
I started a new project with Deno specifically to avoid the NPM mess, and because it was created by Node's creator to fix its shortcomings. I'm new to Web development, but so far the experience has been pretty good.
Nice to see Deno being maintained. The features listed seem pretty substantial.
tuananh 21 hours ago [-]
> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.
and yet Bun's npm compat is much much lower than deno
2. mark libs/executables/etc as 'enhanced security compatible'
3. ...merge by buying out deno?
notnullorvoid 18 hours ago [-]
They may share some goals, but also have differing and opposing goals.
But it's possible that all 3 Deno, Node, and Bun could share some code in the future considering they now all require Rust as part of their build process.
dmit 21 hours ago [-]
> Can someone explain why it sounds like there's such rapid growth of Bun?
In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
satvikpendem 19 hours ago [-]
But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.
sheept 18 hours ago [-]
Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno.
Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.
Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
coffeebeqn 18 hours ago [-]
In my area it feels like it’s competing against go which is a language purposefully designed for the thing we’re building and has a great tool chain already. I never really wanted JavaScript. It’s not a very thoughtfully designed language and the not very good design was made for the browser. I just used node because it was simple to get it working. And you have bun and things like that competing for the space too
moron4hire 17 hours ago [-]
> It’s not a very thoughtfully designed language...
This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew up, learned JS, and have solid careers working in it since that time.
The ECMAScript we have today, and the Typescript extensions of it, is one of the most robust, best performing, intentionally designed dynamic scripting languages on the market. It helps that every major tech corporation in the world has gobs of the stuff bearing loads somewhere in their organizations; they invest massively in making sure it's pretty good.
Before any pedant comes in to post the "Wat" talk, no, JavaScript is not a perfect language. While I personally prefer strictly typed JIT language to it, I still write a lot of it, might even be most of what I write. JavaScript today is as good of a design of a dynamic scripting language as you will find.
arikrahman 11 hours ago [-]
It's not thoughtfully designed. Just look at the effort Rich Hickey took with Clojure and then compare. It's not even in the same league.
dmit 9 hours ago [-]
> no, JavaScript is not a perfect language
Such a brave stance against a claim literally nobody has ever staked.
moron4hire 14 hours ago [-]
(I know it's Brendan Eich, I just didn't notice the damn glass keyboard made its own decisions on what I meant.)
arikrahman 5 hours ago [-]
Rich as in Hickey Freudian slip came out when talking about well designed languages. Can't blame you.
sysguest 18 hours ago [-]
yeah it's such a pity deno's security features could have made recent npm attacks moot...
sheept 18 hours ago [-]
The recent npm supply chain attacks relied on lifecycle scripts, which Deno doesn't run by default, but neither do pnpm or Bun. While Deno, like npm, supports a minimum release age, it doesn't enable it by default.
sysguest 18 hours ago [-]
well deno has 'allow-read' 'allow-write' kind of permission, so if something tries to read from my ~/.ssh or other important folder, it can just block it
even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it
cyanydeez 18 hours ago [-]
the problem was at the start of deno, it didn't integrate with npm; the same way Macintosh used to be free of virus and trojan horses was because people just didn't use it enough.
diegof79 18 hours ago [-]
Mainly DX.
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
steve_adams_86 17 hours ago [-]
There are still some points of friction, but I'm content with it otherwise. The problems Deno resolves for me far outweigh the problems it introduces these days. I think the inflection point was roughly a year ago for me. Prior to that I really wanted to love it, but I ran into too many issues with the tooling I used most often. It was pretty frustrating. These days I rarely encounter anything at all, and I miss it a lot when I use other runtimes.
STRiDEX 18 hours ago [-]
Bun simplified the pain with the ecosystem switch to esm. deno, at the time, made it worse by doing stuff with url based packages that didn’t fully catch on
jitl 18 hours ago [-]
Deno originally was not Node compatible at all, and required you to do everything in a Deno way:
- Deno plugin in editor, otherwise types dont work
- All imports via absolute URL, like Golang
- No backwards compatibility, so no existing code worked.
Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.
Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).
tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects
sysguest 19 hours ago [-]
well benchmarks that's why
if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...
I should check actual perf numbers... well next week or month?
18 hours ago [-]
yroc92 21 hours ago [-]
I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works.
Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.
3uler 21 hours ago [-]
But if you look at the node compliance tests, deno has better compliance now days…
CharlesW 20 hours ago [-]
Insanely better, at 76% Node compliance in Deno 2.8.
Bun 1.3.14 is at just 40.6% with same compliance test.
I'd love to see a site comparing the 3 of them in a similar way.
yoyohello13 20 hours ago [-]
Same, I'm mostly a back end dev but when I dip my toes into frontend for personal projects Deno just seems like the most sane choice. It's really nice to work with. I'm kind of sad it doesn't seem to have taken off among the JS folks.
shepherdjerred 21 hours ago [-]
I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.
So, I switched to Bun and things have been much smoother!
ddosmax556 19 hours ago [-]
I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web.
This is an annoying to do for exactly two platforms: node.js, and deno.
node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!
Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.
Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.
Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.
So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!
I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.
culi 17 hours ago [-]
Bun had some early (imo, extremely deceptive) benchmarks that showed it had really good performance compared to Node and Deno. Zig was also a fledgling hotlang and Bun managed to translate the Zig community into more energy behind Bun. In addition to that, the creator of Bun became a minor celebrity for spending probably over 12 hours almost every single day working on it.
Everything just came together at the right time really quickly and they managed to capitalize on it.
Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.
chamomeal 16 hours ago [-]
I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node.
Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now.
Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice
vorticalbox 21 hours ago [-]
I think the main issue was when deno first came out it used urls for imports then later added support for npm.
By then bun was already a thing and just ate into its share.
VerifiedReports 20 hours ago [-]
Why do you consider URLs a problem?
AgentME 17 hours ago [-]
One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.)
Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.)
(Deno's current support for NPM and JSR avoids these issues.)
VerifiedReports 7 hours ago [-]
Thanks. I use JSR and always pull in the latest, figuring that I'll lock it down when development is done.
vorticalbox 19 hours ago [-]
I don’t consider them a problem at all. It’s how browsers have worked for a long time.
My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction.
Personally I would have like deno it stick with url imports and not added the npm support.
Ryan set out to “fix” his mistakes with node only to fully embrace them again.
satvikpendem 19 hours ago [-]
Annoying to update instead of a package.json, which they now have an equivalent of, realizing their mistake.
spixy 5 hours ago [-]
Because I don't care about that permission system. Server will run in some container or k8s anyway.
And node / bun development is much easier because of many many npm packages.
interstice 5 hours ago [-]
Although the attacks on the NPM ecosystem are making that sound more like a liability by the day.
WorldMaker 21 hours ago [-]
I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.
(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
vmg12 21 hours ago [-]
I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.
WorldMaker 18 hours ago [-]
I'm not suggesting it is a conscious decision point. Node has since done a lot to catch up on "less configuration" but Bun still seems to be growing even as what Bun does well Node starts to emulate. Runtime performance is mentioned in this thread here and elsewhere and while some are attributing that to Zig I think some are overlooking the different runtime experience of JavaScriptCore. It's also the "only" runtime difference between Deno and Bun if you assume that Rust and Zig are similarly performant native layers for some saying they like Bun's runtime performance better than Deno's.
cptmurphy 17 hours ago [-]
Deno permission system is so basic. What you need is capability system
AgentME 17 hours ago [-]
Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)
npn 21 hours ago [-]
because for most people they don't need what deno promises.
me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).
bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.
too bad it is a failed promise now.
robflynn 20 hours ago [-]
I hadn't heard of crystal somehow, I work with ruby a lot so that might be fun to play around with.
giancarlostoro 19 hours ago [-]
Deno is from scratch attempting to pass as many NodeJS tests as possible. Bun piggybacks off the WebkitJS library iirc and shims anything nodejs specific it needs.
wk_end 21 hours ago [-]
When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.
But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.
paulddraper 11 hours ago [-]
Bun prioritized Node.js compatibility.
Deno since adjusted, but Bun gained a lot of market share in the meantime.
nsonha 11 hours ago [-]
"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here).
Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.
vmsp 23 hours ago [-]
I wonder how Deno's faring.
Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.
Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.
That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.
Sammi 18 hours ago [-]
That's a yes and no. Venture funded companies like Anthropic have a history of low follow through with peripheral projects (like Bun is for them). Of course they do - their responsibility is ultimately primarily to their investors - not to Bun. So the risk now is that Anthropic will can Bun whenever they just lose interest or feel it's just a drain that's not contributing directly to their bottom line.
Node.js itself did have trouble finding a corporate home that was interested in providing good support for the project, and that's how we got the oi.js fork of Node, which luckily led to Node being transitioned to a foundation and the projects merged. This whole history is what made me so surprised that Ryan of all people would attempt another js runtime (Deno) project as a corporate project.
And it's the reason I'm staying away from both Bun and Node. I can't afford platform risk like this. I need my startup to be built on a project that has a more reliable future trajectory, which is what you get with a proper open source project (emphasis on project) that you get with Node. Node is stable and still getting features, but most importantly it's not going away.
TeriyakiBomb 19 hours ago [-]
It really doesn't. You think Anthropic will still be in business in 10 years? If they are, it's not likely they'll be in the same shape.
simonw 22 hours ago [-]
It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
allthetime 22 hours ago [-]
Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition.
Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.
pessimizer 18 hours ago [-]
> Running out of money is never the issue with a big company buying an open source project.
I'm going to dare to say that running out of money was often an issue before a big company bought an open source project.
wavemode 21 hours ago [-]
> It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.
Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.
(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)
tarruda 22 hours ago [-]
> safer bet as a dependency.
The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.
simonw 22 hours ago [-]
That was Bun at Anthropic, not uv at OpenAI. (UPDATE: My mistake, this thread is about Bun, not uv.)
matt_kantor 21 hours ago [-]
Is this a joke I'm not getting or are your wires crossed? Bun is the topic of this subthread.
running out of money, for an open source project of almost any kind, is safer than "running into money" with the wrong strings attached
(still reserving judgement on Bun, though — I mean, we'll soon see, one way or the other!)
darkwi11ow 22 hours ago [-]
Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.
wifipunk 21 hours ago [-]
Wasn't it announced that Anthropic is having their first profitable quarter right now in Q2? From what I've personally seen it's all driven by enterprise adoption.
Open source/foreign models are already way cheaper and will work just fine for most use cases but a lot of businesses are already pretty locked in to Claude, and with enterprise costing $240 a year at a 20 seat minimum it's a pretty big investment to make and won't be worth migrating unless the gains are significant.
For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.
It's good to have some options, to prevent the ecosystem from stalling
appplication 21 hours ago [-]
I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.
arikrahman 11 hours ago [-]
I agree that frameworks are abundant but there are not that many JS engine alternatives.
pjmlp 9 hours ago [-]
It has been raining JS engines since Netscape Application Server, alone on Wikipedia there are 22 listed.
arikrahman 5 hours ago [-]
Okay that's great
neals 20 hours ago [-]
Interesting, I'm not aware of that many nodejs alternatives...
rozenmd 22 hours ago [-]
You can already ship single executables, my product's CLI is a Node single executable application
freedomben 23 hours ago [-]
> and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Whoa, did not know that. That's a killer feature!
sirsinsalot 13 hours ago [-]
Code, as a single executable you say?! Whatever will they think of next?
garganzol 18 hours ago [-]
Deno rules, I write some tiny and mid-size web services using it. Works like a Swiss clock, the project ideology is well aligned with the Unix sprit.
In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.
What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.
steve_adams_86 17 hours ago [-]
> Works like a Swiss clock
It really is such a pleasure. It feels almost like a blend of JS and Go. Fast, flexible, slightly saner package management with more powerful capabilities than other JS/TS alternatives, a better security model, better standard library (so to speak)... And very fast. I love it.
cf100clunk 23 hours ago [-]
Deno is a JavaScript and TypeScript runtime, for those who don't recognize the name. Here's a review of Deno 2.6 vs competitors Bun 1.3 and Node.js 25:
It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?
Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?
kloop 22 hours ago [-]
> The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?
As someone who has optimized by reducing/batching heap allocations, 2x seems within the realm of possibility, depending on the exact circumstances.
That being said, iirc, node also has more hooks for things like observability than bun does, which might hurt it here
turadg 22 hours ago [-]
The new *deno pack* command is a nice addition for safe and simple packaging.
Now that Node.js supports importing .ts modules, more repos can use them without a build step or putting any build artifacts in the checkout.
WorldMaker 21 hours ago [-]
Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.
Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.
> Currently there is consensus that Node.js should NOT run TypeScript files inside `node_modules. It is not supported to avoid package maintainers to release TS only package.
notnullorvoid 17 hours ago [-]
It sounds a lot like DNT (https://github.com/denoland/dnt) which has existed for a long time, but having it in Deno cli does bring significant visibility.
ale 21 hours ago [-]
I think if Deno had held on to their initial values for a little longer the pressure towards node compatibility would have been mended by AI agents, because a lot of the pressure is the result of skill issues: if the only way you know how to set up is using express.js then any subsequent tool or runtime must provide a similar abstraction for a “smooth” transition, regardless of how bad the first solution was in the first place. Nowadays you introduce devs to new tech by delivering your product with a set of skills that in practice have replaced documentation and sometimes can be very good at showing better alternative approaches to whatever you’re building.
pjmlp 9 hours ago [-]
If the JS/TS SDK I get from a SaaS vendor doesn't work on Deno without changes, I am not going to spend one second to make it work.
rutierut 14 hours ago [-]
As someone who has used Deno on multiple hobby projects, I’m convinced Deno is where the JS ecosystem should be heading.
Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.
syrusakbary 14 hours ago [-]
It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).
A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second.
The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.
If Deno continues this trajectory then there is less and less reason to use it over Node.
garganzol 4 hours ago [-]
I somewhat agree with you.
For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...
eskori 1 days ago [-]
By the time I read this, the blog post doesn't exist yet:
> The release post for v2.8 is not yet published.
> Check GitHub releases page for the latest release status of Deno.
I wrap most node-isms and use deno as the runtime. Works well. If a project is pure typescript I just have deno run it. Extra options for security are great, installation scripts disabled by default, etc.
If you're using node directly, please stop. At a minimum use Bun.
With agentic work, there is little reason to use anything besides Rust and Typescript in any case. Room to disagree but type safety, memory safety, and a large corpus of work is critical. Agents need difficult errors and baked in patterns they navigate it easily. For UI, Typescript makes the most sense just because of the mass of design examples.
XCSme 20 hours ago [-]
Is anyone here using Deno in production?
garganzol 17 hours ago [-]
Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.
XCSme 17 hours ago [-]
Nice, at what scale?
garganzol 17 hours ago [-]
B2B, ~10k active users/month.
danborn26 16 hours ago [-]
The continuous performance improvements in Deno are really impressive. Node compatibility getting better with every release makes the transition a lot easier for existing projects.
Curosinono 21 hours ago [-]
I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
hollowturtle 21 hours ago [-]
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
Curosinono 15 hours ago [-]
It is a language, it doesn't matter to what it is downcompiled to be able to be run in a browser.
Its now 13 years old, not a hard language to have a proper runtime for it and it would just get rid of all the npm stuff.
And for the amount of typescript we now have, it would be worth it to have proper native support.
lelanthran 6 hours ago [-]
> It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean?
It means that `<script src="some-url.ts">` works.
VerifiedReports 20 hours ago [-]
All good questions. But... it would simply eliminate a step and result in a single language.
Python supports types and is interpreted, right?
hollowturtle 15 hours ago [-]
Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being able to do more inside the browser, like rendering, managing user input, accessibility, dom manipulation. Then u could compile your favorite static types lang down to wasm. Hell even a strictier version of TS could be made to do that, iirc there's something similar called assembly script
ngrilly 3 hours ago [-]
Python type annotations are available at runtime, which can be used for serialization and validation (for example in FastAPI).
sirsinsalot 13 hours ago [-]
I mean, all typescript does is serve no purpose except for an LSP and documenting type intention really. It isn't much different to Python type annotation.
antod 15 hours ago [-]
Python containing type hints doesn't get transpiled the way typescript does. The transpiling rewrites the TS to varying degrees depending on the target and the extra TS features being used.
Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints.
There's a bit more going on with TS that you couldn't just have the runtime ignore the types.
sirsinsalot 13 hours ago [-]
As I understand it you can, in fact node 23 has a type stripping feature. I could be wrong.
wpollock 15 hours ago [-]
> Because "it doesn't exist". It's just a layer on top of js, ...
C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C.
There is nothing preventing TypeScript from becoming "native" in a similar way.
pjmlp 9 hours ago [-]
Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes.
If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.
sirsinsalot 13 hours ago [-]
It doesn't make any sense tho. Typescript is nothing much to do with runtime. It's a build/dev concern. To get JS from TS you're mostly removing the type annotations.
Theres no reason to ship TS to an end user browser.
wpollock 13 hours ago [-]
> Theres no reason to ship TS to an end user browser.
As things are now, developers write code in TypeScript, then debug and update code in Javascript. It might not be much of a reason, but a single language throughout is surely easier on developers and maintainers.
WorldMaker 21 hours ago [-]
Because standardization is a political process that takes time and consensus to achieve?
TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.
WorldMaker 14 hours ago [-]
Typescript certainly hasn't been resting on its laurels.
Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine.
I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM.
Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation.
Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)
yoyohello13 20 hours ago [-]
My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.
sirsinsalot 13 hours ago [-]
Or at least some kind of cursor based text buffer tree that wasm can bind to the dom/shadow tree, rather than a fuller API
vmg12 21 hours ago [-]
Likely because everybody would still strip types, bundle and minify their typescript code anyway.
brazukadev 14 hours ago [-]
it is still a DX improvement
tuananh 21 hours ago [-]
JS promise to never break the web. can't say the same about TS
bel8 1 hours ago [-]
JS can't really break the web.
It's a trillion+ market.
If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.
IshKebab 20 hours ago [-]
There wouldn't be any benefit. It's not sound so it can't really be used to improve performance.
There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace:
The release post for v2.8 is not yet published.
Check GitHub releases page for the latest release status of Deno.
21 hours ago [-]
IshKebab 20 hours ago [-]
I don't know why they copied NPM's backwards `npm install/ci` thing. Most people think that `install` does use the lock file.
just123 19 hours ago [-]
I like Deno for the web standards. I think it should be sponsored by the government for it to flourish.
danielcasper 14 hours ago [-]
I literally just discovered Deno today. I wish there was Deno for Python / WASM path was really mature. Maybe I'm missing something here, but trying to secure both a Python runtime and JS runtime for AI.
csjh 14 hours ago [-]
It should be pretty mature outside of Wasi. To be fair, there's really nothing that's super mature in terms of Wasi support, except maybe Wasmtime
rochacon 11 hours ago [-]
For Python, `uv` [1] delivers a similar experience. Faster dependencies. Better dependency management with `pyproject.toml`. Just use it with `uv run` or `uvx`.
npm by default: When I tried Deno ~1-2 years ago - I immediately shinned myself on this and decided to wait for more sensible defaults. (I've not followed closely, just the basic story)
And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.
Well done Deno team.
mohsen1 22 hours ago [-]
> Deno now defaults to npm:
This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense.
I'm wondering how Deno would've been received if it supported npm and package.json from day 1.
afavour 22 hours ago [-]
I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.
WorldMaker 21 hours ago [-]
I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)
mmastrac 21 hours ago [-]
I previously worked at Deno and even with all that tbh, I am not sure the http deps were the right way to go. I've really wanted to like them but package managers really have advantages.
I would not say npm was the right direction. I actually was a fan of JSR (didn't work on it but all my experience with it was great)
pjmlp 22 hours ago [-]
As someone that works in projects with standard IT tools, not supporting NPM made it a non starter for us.
No way it would go through standard build pipelines, or team skills.
afavour 20 hours ago [-]
Oh, for sure. But I'm old enough to remember when standard IT tools would have never supported Node in the first place and the idea of JS on the server made everyone scream. You just need to build demand for that support.
pjmlp 20 hours ago [-]
For us the demand is, does it run everything that either Angular or Next.js require, or the SDKs from headless SaaS products.
ale 22 hours ago [-]
"standard" IT tools?
pjmlp 20 hours ago [-]
Yes, IT from customer, or agency delivery operations, dictates what are the official tools in specific projects, including 3rd party dependencies in internal repos, and CI/CD is cut off from accessing public Internet.
notnullorvoid 17 hours ago [-]
This is a really odd change. Deno already supported installing npm packages, this only removes the "npm:" prefix requirement for cli commands. Considering the nightmare that is npm, I was quite happy for jsr to become the defacto registry for the Deno ecosystem. If anything I would've expected the "jsr:" prefix to be the default.
I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?
Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.
A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).
So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.
I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.
Edit: And Deno is now more compatible with node than bun.
"Probably"? Are you saying there's a chance he wasn't right?
I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.
Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.
The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.
It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.
This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.
we nodejs devs were just ignorant/lazy
npmjs should mark libs "deno compatible" and move over to deno gradually for security
Nice to see Deno being maintained. The features listed seem pretty substantial.
and yet Bun's npm compat is much much lower than deno
https://x.com/rough__sea/status/2057579066744881188
Seriously, they're both Rust now. They share goals.
1. add 'enhanced security mode' that's actually 'deno-compatible/like' (permissions, etc)
2. mark libs/executables/etc as 'enhanced security compatible'
3. ...merge by buying out deno?
But it's possible that all 3 Deno, Node, and Bun could share some code in the future considering they now all require Rust as part of their build process.
In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.
Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew up, learned JS, and have solid careers working in it since that time.
The ECMAScript we have today, and the Typescript extensions of it, is one of the most robust, best performing, intentionally designed dynamic scripting languages on the market. It helps that every major tech corporation in the world has gobs of the stuff bearing loads somewhere in their organizations; they invest massively in making sure it's pretty good.
Before any pedant comes in to post the "Wat" talk, no, JavaScript is not a perfect language. While I personally prefer strictly typed JIT language to it, I still write a lot of it, might even be most of what I write. JavaScript today is as good of a design of a dynamic scripting language as you will find.
Such a brave stance against a claim literally nobody has ever staked.
even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
- Deno plugin in editor, otherwise types dont work
- All imports via absolute URL, like Golang
- No backwards compatibility, so no existing code worked.
Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.
Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).
tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects
if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...
I should check actual perf numbers... well next week or month?
Bun 1.3.14 is at just 40.6% with same compliance test.
https://node-test-viewer.deno.dev/
I'd love to see a site comparing the 3 of them in a similar way.
So, I switched to Bun and things have been much smoother!
This is an annoying to do for exactly two platforms: node.js, and deno.
node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!
Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.
Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.
Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.
So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!
I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.
Everything just came together at the right time really quickly and they managed to capitalize on it.
Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.
Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now.
Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice
By then bun was already a thing and just ate into its share.
Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.)
(Deno's current support for NPM and JSR avoids these issues.)
My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction.
Personally I would have like deno it stick with url imports and not added the npm support.
Ryan set out to “fix” his mistakes with node only to fully embrace them again.
And node / bun development is much easier because of many many npm packages.
(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).
bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.
too bad it is a failed promise now.
But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.
Deno since adjusted, but Bun gained a lot of market share in the meantime.
Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.
Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.
Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.
Who thinks this is a positive?!
Node.js itself did have trouble finding a corporate home that was interested in providing good support for the project, and that's how we got the oi.js fork of Node, which luckily led to Node being transitioned to a foundation and the projects merged. This whole history is what made me so surprised that Ryan of all people would attempt another js runtime (Deno) project as a corporate project.
And it's the reason I'm staying away from both Bun and Node. I can't afford platform risk like this. I need my startup to be built on a project that has a more reliable future trajectory, which is what you get with a proper open source project (emphasis on project) that you get with Node. Node is stable and still getting features, but most importantly it's not going away.
Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.
I'm going to dare to say that running out of money was often an issue before a big company bought an open source project.
I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.
Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.
(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)
The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.
(still reserving judgement on Bun, though — I mean, we'll soon see, one way or the other!)
Open source/foreign models are already way cheaper and will work just fine for most use cases but a lot of businesses are already pretty locked in to Claude, and with enterprise costing $240 a year at a 20 seat minimum it's a pretty big investment to make and won't be worth migrating unless the gains are significant.
Is it different from the status quo prior?
Wouldn't node be the safest bet as a dependency?
https://github.com/yt-dlp/yt-dlp/issues/16766
Whoa, did not know that. That's a killer feature!
In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.
What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.
It really is such a pleasure. It feels almost like a blend of JS and Go. Fast, flexible, slightly saner package management with more powerful capabilities than other JS/TS alternatives, a better security model, better standard library (so to speak)... And very fast. I love it.
https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...
Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?
As someone who has optimized by reducing/batching heap allocations, 2x seems within the realm of possibility, depending on the exact circumstances.
That being said, iirc, node also has more hooks for things like observability than bun does, which might hurt it here
For those using Node.js, a similar single command is available with https://www.npmjs.com/package/ts-node-pack
Now that Node.js supports importing .ts modules, more repos can use them without a build step or putting any build artifacts in the checkout.
Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.
They made that intentionally at the beginning:
> Currently there is consensus that Node.js should NOT run TypeScript files inside `node_modules. It is not supported to avoid package maintainers to release TS only package.
Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.
Good work to everyone on the Deno team!
[1] https://edgejs.org/
Full time for the last three months.
Deno replaced a pnpm monorepo I was using.
The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.
If Deno continues this trajectory then there is less and less reason to use it over Node.
For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...
> The release post for v2.8 is not yet published.
> Check GitHub releases page for the latest release status of Deno.
The release is here: https://github.com/denoland/deno/releases/tag/v2.8.0
EDIT: Formatting
If you're using node directly, please stop. At a minimum use Bun.
With agentic work, there is little reason to use anything besides Rust and Typescript in any case. Room to disagree but type safety, memory safety, and a large corpus of work is critical. Agents need difficult errors and baked in patterns they navigate it easily. For UI, Typescript makes the most sense just because of the mass of design examples.
Its now 13 years old, not a hard language to have a proper runtime for it and it would just get rid of all the npm stuff.
And for the amount of typescript we now have, it would be worth it to have proper native support.
It means that `<script src="some-url.ts">` works.
Python supports types and is interpreted, right?
Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints.
There's a bit more going on with TS that you couldn't just have the runtime ignore the types.
C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C.
There is nothing preventing TypeScript from becoming "native" in a similar way.
If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.
Theres no reason to ship TS to an end user browser.
As things are now, developers write code in TypeScript, then debug and update code in Javascript. It might not be much of a reason, but a single language throughout is surely easier on developers and maintainers.
https://github.com/tc39/proposal-type-annotations
Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine.
I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM.
Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation.
Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)
It's a trillion+ market.
If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.
There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace:
https://github.com/tc39/proposal-type-annotations
[1] https://github.com/astral-sh/uv
And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.
Well done Deno team.
This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense.
I'm wondering how Deno would've been received if it supported npm and package.json from day 1.
I would not say npm was the right direction. I actually was a fan of JSR (didn't work on it but all my experience with it was great)
No way it would go through standard build pipelines, or team skills.