I just tried to migrate using their `deno install` -> `deno task dev` instructions, and I got an error about vite needing a newer version of Node.
I'm not pathologizing deno, and I have (and will continue to) consistently tried to migrate my projects to deno, first from npm, then from pnpm, and now from bun. But every single time I've tried, there has been some kind of stupid "edge case", "simple fix" issue like this that stops me in my tracks. It's not a huge deal, but the simple fact is, when I run the project using bun, it runs. When I try it using deno, it doesn't. That has been a consistent pattern every single time I've tried. Last time, deno blew up because it wasn't able to work out the IndexedDB api calls I was using without some kind of bridge/shim/environment config. These are terribly minor issues, but it's the lack of care for the details that really sours me on this stuff.
Obviously, deno should have used the version of vite that bun did which would have worked with the version of node on this machine. But even barring that, they could have dropped a little note around the instructions that says "if some packages need updates, you can run X command to do that". Even that would have allowed me to just move on, instead of forcing me to query the solution and hope for the best. Like I said, none of this is damning. It's just the exact kind of friction that prevents immediate adoption. At least for me.
Gee, sorry to hear that. It's Bartek from the Deno team here. This is really a whack-a-mole. We currently present the latest stable Node.js version (26.3.0) so the error is not correct - I bet it's probing for something stupid like no of arguments a certain function supports. Is your project open source so I can take a look myself?
unfortunately, while the project is in the public domain, it's pre-alpha so I haven't made the repo public yet.
but the project is structured the same as another public domain project I've built, and I just checked to make sure it has the same issue. I've gone ahead and made that project public so you can give it a try[0].
but, just to be clear, I don't think the message is wrong? The Node version on this machine is out of date. And when comparing the deno.lock file to the bun.lock file, I can see that the deno.lock has a slightly newer version (8.1 vs 8.0) of vite. So I think the message could be correct and is just telling me to update my version of Node, which is perfectly reasonable. It's just the discrepancy between not needing the newer version of vite/node on bun while invoking an error using deno. Feels like I should have either gotten perfectly matching versions, or error messages (with commands) to update node.
in any case, if you're still interested in seeing the error yourself, my steps were:
1. clone the repo
2. run deno install
3. run deno task dev
You can have AI do way more automated testing in a loop, let cheap models run 24/7 so all edge cases can be found over time by pulling random repos, you must make sure the agent is entirely autonomous, ask another agent to make a list (also in a loop so it keeps appending to it) and another agent that try to fulfill "run it with Deno".
Because none of that requires "AI". You can use a script to clone GitHub top NPM repos (by whatever measure), and then 'simply' try to migrate them to Deno and log all the errors and warnings. Maybe you compile those errors in a neat list with an LLM, and ask it to emphasize things it considers important.
Parent is getting downvoted because they're suggesting something that is akin to "why are you running this simple, reliable efficient Python script instead of feeding inputs to an LLM and praying you get the outputs you want".
One of the most fascinating things to fall out of the AI apocalypse is seeing how abundant AI access amplifies the qualities of a company.
IMO, Deno has always been more methodical, more focused (maybe too focused?) on standards. But now the Deno team is on the right track: using Claude extensively to improve the node.js compat which was absolutely herculean if not impossible before AI. [+]
On the other hand, Bun has always played a bit fast and loose, chasing metrics at the cost of stability. Access to abundant AI has sent that project off the rails.
Disclaimer: Former Deno engineer - I'm obviously going to have some biases. All IMO of course, but if you ask me I'd still bet on Deno in the long term, and I personally still use it for any .ts projects.
[+] There might be a dozen people in the world that know how sensitive and subtle the timing and ordering in the JS event loop is and how meticulous just this single part needs to be for major node.js projects not to completely crap themselves.
To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one).
For example, those two issues recently directly affected my projects:
I think I'll probably just go back to normal Node because it's stable and won't break things like this between minor releases, plus it's not full-on vibe-developed like Deno and Bun.
P.S.: Deno does genuinely have good parts: built-in type checking, LSP server, formatter with sane defaults, and so on. I'm just very disappointed that they seem to be focusing less on the actual core runtime.
Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.
Maybe reality isn't represented by the git logs, but according to them, you appear to have composed, reviewed and merged 131 commits affecting 58 files and 6000 lines -- a task that you say amounts to "replacing the engine while driving" -- in the span of one week.
If that's accurate, of course your reliance on AI is at fault here. It invites you to mistake velocity for quality and conflate test satisfaction for completion.
Without AI, this effort would likely have taken much longer and an experienced team would have approached it with due meticulousness, being especially stringent in review. Absorbed in it, the work would have weighed on their unconscious while they slept, with "Ah shoot, did I consider XYZ?" moments striking them in the shower. Ideally, familiar with the specific contributors (i.e. you) and their style of work, the reviewer who later consider merging the work would have ideas what to watch out for and would spend extra time looking at the details you might not have fully considered. It's a whole decades-matured craft practice that can do a pretty good job of making sure that a refactor of this scale doesn't land in main too broken.
And while that version still probably wouldn't have been entirely flawless either, or might never have even been attempted because of its greater calendar and attention burden, that doesn't mean that using AI wasn't responsible for why and how this version is broken.
This is exactly how AI makes things worse and why many people are wary of relying on third-party projects that embrace it too blithely. If you're going to use it, that's great, and maybe it will help you keep landing big features more quickly than otherwise -- but at least accept responsibility for the tradeoffs that you're inviting when you do so.
> Rewrite the entire node:http stack to use llhttp (Node.js's HTTP parser)
Can we please not turn Deno into junk? If you do the above -- what's the point of Deno?
Once you bolt everything on like that you might as well just use Node.
Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...
We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years. So earlier this year we decided to make it compatible (by using llhttp to have very high coverage - at the moment 88% compatibility for node:http module) and then focus on improving performance and slowly chipping away llhttp parts while keeping compatibility.
It's so easy for others to casually dismiss how difficult of a problem it is to get this right, especially, as you say, this is happening in flight for many thousands of users. Kudos to you for being transparent and building a genuinely cool and useful platform.
> We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years.
Are you sure you "failed"? Maybe there was good enough compatibility and that wasn't the problem?
The problem sounds like a business 1 where you're after more users and you deem this "magic compatibility" is fixing it. Well maybe that's not it.
A lot of people tried Deno and even tried to build libraries for it back some years ago. What you "failed" at is building the traction, ecosystem and community support.
Compatibility doesn't buy you moat. Deno specific ecosystem, libraries and services etc do.
Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.
AI lets people be reaaaaaaally "productive" when leaning into entirely the wrong work. Deno has no future if all it wants to be is a clone of node, so it just seems to me like your work is to speed the collapse
Because I wanted native TypeScript support which Node only gained relatively recently and only partially, plus the issues I showed are regressions - they worked fine in earlier Deno versions.
node randomly broke production for us last week https://github.com/nodejs/node/issues/63989 not sure it can be considered "stable and won't break things like this between minor releases"
Deno is a great example of how taking VC investments tanks the viability of an open source project. They keep focusing on money driving projects for an extremely small + fractured community (let's be honest here, whose only customers who are likely other VC holdings), oh and having continuous major layoffs does not signal good leadership qualities.
Ryan Dahl is assuredly a poor steward of open source software if these are the results. Node is popular because of the massive, inclusive community behind it; not because of a few rock star individuals, but for the VC mindset it's much easier to control an individual programmer than a community of them.
Only wonders are what other communities VC will try to rat fuck next, how fast do we think Evan You will speed run this exact same arc (which has already happened a dozen times in lived memory), and why does Bryan Cantrill feel like the only smart tech executive that doesn't fall into these traps?
I just tried to migrate using their `deno install` -> `deno task dev` instructions, and I got an error about vite needing a newer version of Node.
I'm not pathologizing deno, and I have (and will continue to) consistently tried to migrate my projects to deno, first from npm, then from pnpm, and now from bun. But every single time I've tried, there has been some kind of stupid "edge case", "simple fix" issue like this that stops me in my tracks. It's not a huge deal, but the simple fact is, when I run the project using bun, it runs. When I try it using deno, it doesn't. That has been a consistent pattern every single time I've tried. Last time, deno blew up because it wasn't able to work out the IndexedDB api calls I was using without some kind of bridge/shim/environment config. These are terribly minor issues, but it's the lack of care for the details that really sours me on this stuff.
Obviously, deno should have used the version of vite that bun did which would have worked with the version of node on this machine. But even barring that, they could have dropped a little note around the instructions that says "if some packages need updates, you can run X command to do that". Even that would have allowed me to just move on, instead of forcing me to query the solution and hope for the best. Like I said, none of this is damning. It's just the exact kind of friction that prevents immediate adoption. At least for me.
Gee, sorry to hear that. It's Bartek from the Deno team here. This is really a whack-a-mole. We currently present the latest stable Node.js version (26.3.0) so the error is not correct - I bet it's probing for something stupid like no of arguments a certain function supports. Is your project open source so I can take a look myself?
unfortunately, while the project is in the public domain, it's pre-alpha so I haven't made the repo public yet.
but the project is structured the same as another public domain project I've built, and I just checked to make sure it has the same issue. I've gone ahead and made that project public so you can give it a try[0].
but, just to be clear, I don't think the message is wrong? The Node version on this machine is out of date. And when comparing the deno.lock file to the bun.lock file, I can see that the deno.lock has a slightly newer version (8.1 vs 8.0) of vite. So I think the message could be correct and is just telling me to update my version of Node, which is perfectly reasonable. It's just the discrepancy between not needing the newer version of vite/node on bun while invoking an error using deno. Feels like I should have either gotten perfectly matching versions, or error messages (with commands) to update node.
in any case, if you're still interested in seeing the error yourself, my steps were: 1. clone the repo 2. run deno install 3. run deno task dev
[0] https://gitlab.com/cynic-devs/magnitce-code-example
You can have AI do way more automated testing in a loop, let cheap models run 24/7 so all edge cases can be found over time by pulling random repos, you must make sure the agent is entirely autonomous, ask another agent to make a list (also in a loop so it keeps appending to it) and another agent that try to fulfill "run it with Deno".
I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos
You're getting downvoted because "AI bad" but this is actually a good idea.
Because none of that requires "AI". You can use a script to clone GitHub top NPM repos (by whatever measure), and then 'simply' try to migrate them to Deno and log all the errors and warnings. Maybe you compile those errors in a neat list with an LLM, and ask it to emphasize things it considers important.
Parent is getting downvoted because they're suggesting something that is akin to "why are you running this simple, reliable efficient Python script instead of feeding inputs to an LLM and praying you get the outputs you want".
Respect yourself by respecting the craft.
One of the most fascinating things to fall out of the AI apocalypse is seeing how abundant AI access amplifies the qualities of a company.
IMO, Deno has always been more methodical, more focused (maybe too focused?) on standards. But now the Deno team is on the right track: using Claude extensively to improve the node.js compat which was absolutely herculean if not impossible before AI. [+]
On the other hand, Bun has always played a bit fast and loose, chasing metrics at the cost of stability. Access to abundant AI has sent that project off the rails.
Disclaimer: Former Deno engineer - I'm obviously going to have some biases. All IMO of course, but if you ask me I'd still bet on Deno in the long term, and I personally still use it for any .ts projects.
[+] There might be a dozen people in the world that know how sensitive and subtle the timing and ordering in the JS event loop is and how meticulous just this single part needs to be for major node.js projects not to completely crap themselves.
To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one).
For example, those two issues recently directly affected my projects:
- https://github.com/denoland/deno/issues/34297
- https://github.com/denoland/deno/issues/35289
Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208
I think I'll probably just go back to normal Node because it's stable and won't break things like this between minor releases, plus it's not full-on vibe-developed like Deno and Bun.
P.S.: Deno does genuinely have good parts: built-in type checking, LSP server, formatter with sane defaults, and so on. I'm just very disappointed that they seem to be focusing less on the actual core runtime.
> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208
Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.
> Using AI here is not really at fault here
Maybe reality isn't represented by the git logs, but according to them, you appear to have composed, reviewed and merged 131 commits affecting 58 files and 6000 lines -- a task that you say amounts to "replacing the engine while driving" -- in the span of one week.
If that's accurate, of course your reliance on AI is at fault here. It invites you to mistake velocity for quality and conflate test satisfaction for completion.
Without AI, this effort would likely have taken much longer and an experienced team would have approached it with due meticulousness, being especially stringent in review. Absorbed in it, the work would have weighed on their unconscious while they slept, with "Ah shoot, did I consider XYZ?" moments striking them in the shower. Ideally, familiar with the specific contributors (i.e. you) and their style of work, the reviewer who later consider merging the work would have ideas what to watch out for and would spend extra time looking at the details you might not have fully considered. It's a whole decades-matured craft practice that can do a pretty good job of making sure that a refactor of this scale doesn't land in main too broken.
And while that version still probably wouldn't have been entirely flawless either, or might never have even been attempted because of its greater calendar and attention burden, that doesn't mean that using AI wasn't responsible for why and how this version is broken.
This is exactly how AI makes things worse and why many people are wary of relying on third-party projects that embrace it too blithely. If you're going to use it, that's great, and maybe it will help you keep landing big features more quickly than otherwise -- but at least accept responsibility for the tradeoffs that you're inviting when you do so.
> Rewrite the entire node:http stack to use llhttp (Node.js's HTTP parser)
Can we please not turn Deno into junk? If you do the above -- what's the point of Deno?
Once you bolt everything on like that you might as well just use Node.
Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...
We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years. So earlier this year we decided to make it compatible (by using llhttp to have very high coverage - at the moment 88% compatibility for node:http module) and then focus on improving performance and slowly chipping away llhttp parts while keeping compatibility.
It's so easy for others to casually dismiss how difficult of a problem it is to get this right, especially, as you say, this is happening in flight for many thousands of users. Kudos to you for being transparent and building a genuinely cool and useful platform.
> We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years.
Are you sure you "failed"? Maybe there was good enough compatibility and that wasn't the problem?
The problem sounds like a business 1 where you're after more users and you deem this "magic compatibility" is fixing it. Well maybe that's not it.
A lot of people tried Deno and even tried to build libraries for it back some years ago. What you "failed" at is building the traction, ecosystem and community support.
Compatibility doesn't buy you moat. Deno specific ecosystem, libraries and services etc do.
> what's the point of Deno?
To demonstrate how amazing bun is in comparison.
Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility
Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.
AI lets people be reaaaaaaally "productive" when leaning into entirely the wrong work. Deno has no future if all it wants to be is a clone of node, so it just seems to me like your work is to speed the collapse
Well if Node compatibility is your big deal then yeah, why not just use it?
I started a new project on Deno to avoid the NPM mess. Node compatibility was a distraction for the product.
I'm tired of everything depending on Node. Assuming that everybody uses it is lazy.
Because I wanted native TypeScript support which Node only gained relatively recently and only partially, plus the issues I showed are regressions - they worked fine in earlier Deno versions.
To be fair, you can't blame a person for thinking that a runtime created by the same guy who created Node would work with Node.
Time for someone to spin up Endo, but this time no cute ideas for real.
node randomly broke production for us last week https://github.com/nodejs/node/issues/63989 not sure it can be considered "stable and won't break things like this between minor releases"
Welp, guess the only option is to stay on some single version then and hope it doesn't get critical security issues...
Deno went downhill as soon as they introduced Node compatibility. It promised a better way of doing things, then stooped back down to Node fuckery.
definitely hard to beat Bun at the moment, the live reload is crazy good
Agreed. Bun is awesome! I see no reason to switch to deno.
Deno is a great example of how taking VC investments tanks the viability of an open source project. They keep focusing on money driving projects for an extremely small + fractured community (let's be honest here, whose only customers who are likely other VC holdings), oh and having continuous major layoffs does not signal good leadership qualities.
Ryan Dahl is assuredly a poor steward of open source software if these are the results. Node is popular because of the massive, inclusive community behind it; not because of a few rock star individuals, but for the VC mindset it's much easier to control an individual programmer than a community of them.
Only wonders are what other communities VC will try to rat fuck next, how fast do we think Evan You will speed run this exact same arc (which has already happened a dozen times in lived memory), and why does Bryan Cantrill feel like the only smart tech executive that doesn't fall into these traps?