I helped Deno bring the Standard Library to v1 [as a contractor] and have always loved the team and philosophy. But these days I’m saddened by what seems to be their slow decline into obscurity. After the layoffs, there seems to be no roadmap, no comms, etc. I’m just so curious as to where they’re heading and still hope the best for it. I’ve always liked Deno more than Node and Bun.
The saddest part is that there have surely been acquisition offers from bigger players that they declined, but given how strongly the market favors the hyperscalers and super-capitalized AI companies an acquisition might’ve been their only sensible play. You either sell or get squeezed out.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.
GH still has its own login system thankfully, and I can't even sign in with Microsoft or link my Linkedin profile in any way (at least from Github.com; I'm sure there's a public Linkedin-developed Github App). I'll take what I can get.
They've been a great steward of GitHub. You people have no perspective. They've kept an insanely generous free tier - free private repos, free CI runners including windows and Mac! And no ads.
Deno is still an easy pick for me because of its built-in test-runner (deno test), linter (deno lint), and type checker (deno check). I've used many different npm packages for these things in previous projects and I have no idea what the new hotness and proper configuration is for all of these things in a new node project, so I really value the simplicity of Deno for it all. Also JSR and Deno for publishing Typescript libraries is still so much easier than setting up a Typescript node project and configuring it to publish compiled code, and it gets you documentation pages generated from your tsdoc comments too, which I never knew how to do outside of JSR.
The new hot lint (for me) is Oxlint. Literally a 300x speed improvement on our monorepo compared to eslint for the same ruleset. It’s amazing, especially in combination with Oxfmt instead of prettier.
With LLMs becoming prevalent, it seems people are “quitting” their projects more quickly. Not necessarily a bad thing, but just shows that the opportunity cost is too high right now if you’re building the wrong thing. Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
> Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.
LLMs don't reach for it because the frontier companies don't have it as the default. I've instructed Claude to NOT use React (use SvelteKit), NOT use Node (use Deno or Bun), among other things.
The industry defaults are trash but it is what it is.
Oh man they all reach for the nextjs dumpster fire. Every single vibe coded app is that stack. At least many are backed with supabase (Postgres is a same choice).
Please excuse my language, but that's only the case if you're a complete imbecile and can't write a for loop to save your life.
An LLM doesn't "reach" for anything, because you tell it what to do. You go "use this tool, to do that thing, in this way, here's a bunch of written guidance on how exactly to do that, and if you run into issues ask me". Any other use is glorified copy-paste slop code and will end up with a worse codebase than if you let an egomaniac run amok on a single codebase for 20 years.
This is part of how LLMs are hurting progress. People are moved away from things like StackOverflow or new projects where they pose and answer questions with real people, or create novel things, and pushed more and more to whatever answers or solutions the LLMs will spit out for them.
I added a wrapper script around Deno to my agent’s allowlist to take advantage of its permissions system, and instructed it to use Deno instead of Python or bash commands. It’s worked pretty well.
"Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now"
Well, in my case I suddenly had deno installed, while letting run fable in auto mode, even node was already there and I had to look up what deno was. "Ah, that node replacement."
Turns out the 'boring enterprise runtime' spent its time actually shipping stability while everyone else was chasing the next shiny runtime hype cycle.
It's great that they developed alternatives to Node, I was just getting annoyed with all the users trying to bait in more users like "why don't you use [Deno/Bun], it's completely compatible" when it's not. Same with all the Python interpreters besides CPython.
I know Bun is kinda not the fan favorite right now with the Anthropic acquisition and the Rust re-write drama and such, but on every one of the dimensions listed in this article, I like Bun better than either Node or Deno.
Bun is awesome. It feels great these days to start with bun or convert a nodejs app over and reduce deps down, sometimes to 0.
Ive just gone all in, no more mega bash scripts that constantly bug out on the silliest problems whenever you try to do anything complex involving a list data type.
It just feels like its something you can pretty much always bend towards what you need without needing to breakout into another language and I'm keen to see some of the new performance stuff their continuing to work on.
I'm building on Deno for the past 2 years and I have no regrets. It still delivers me why I picked it over node. Less config, less packages to install, good DX.
As a casual both Bun and Deno user, I have generally preferred Bun to Deno unless sandboxing is a concern.
I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.
I am not sure about deno not being innovative - I've recently started using deno for it's new desktop app support only (https://docs.deno.com/runtime/desktop/)
Oh look, we’re consolidating again. My only gripe with it was that it wouldn’t directly run Typescript. Other than that it just felt a little ... antiquated.
Bun seems popular too, what would be reasons to choose it?
Bun is much much more lighter than node or deno. If you don't mind the controversy around the rust rewrite, it's objectively the better option in most cases.
A month before the rewrite I was hitting soundness bugs on fairly trivial JS code. I remember right, under HMR re-exports of module variables caused a snapshot, and importers of the reexport saw stale values.
I reported it, watched robobun write an unhinged +300 -0 patch which quickly got LGTM'd and merged.
I hope now that we've moved past AGI and into the ASI era things are better.
I made a fairly straight forward webapp with Bun and let Claude check whether it was actually better than Node. Nope, Node consumed less memory and used about the same CPU as Bun. I didn't switch, because it costs tokens, but Node's reputation seem to be based on its legacy more than on today's use.
> Why? Just strip the types bro, I know you can! Let me sign a deal with the devil!
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).
> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.
There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.
Yes, but your TypeScript code has to be checked against the libraries in node_modules, and it is significantly costlier to check against implementation files (the .ts/.mts files) than the produced declaration files (the .d.ts files).
Type stripping can and does ignore tsconfig.json files, from the provided link:
> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.
Of course import aliases and such features would break.
I wanted Deno to succeed to have a single standardised toolchain, but with Deno having its own APIs you'd effectively have to architect your application to be a "Deno app" and it created two different ecosystems. The best way to make your app portable would be to use the provided Node APIs, cutting a lot of the value from Deno.
The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.
Sandboxing and being more aligned with web standards, though admittedly on the latter I haven't checked back in on node with to see if there's been a push towards having the same tools as the browser engines instead of import('garys-crypto') etc
I reluctantly do anything with JS/TS but if I have to, I'll pick Deno because I'm sick of needing to install a dozen dependencies which then require their own thousands of dependencies.
Even if I pick modern tooling, say Biome for linting and formatting, Vite for bundling and handling the build, Vitest for unit testing, and finally TypeScript.
Once that's done, it's then remembering the right values needed in package.json and tsconfig.json to do the right thing and Just Work TM. It's 2026 and all this slop still assumes I don't want ES modules.
I could spend a whole morning on this bullshit. With Deno, I don't have to.
I always contrast that with my preferred languages, like C#/.NET. Project setup takes literally a few minutes. Deno and .NET have that in common, there is a single CLI for it.
The Deno JSR/STD thing also has a whole collection of libraries and data structures I'd otherwise need to get from NPM.
> There is no reason to use the Deno runtime today.
LMAO okay bro.
With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.
It's great that we now have 3 major JS server environments: Node.js, Deno and Bun. The competition keeps them all in check.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.
TypeScript is, objectively, the superior option—especially in the presence of LLMs, because the type safety is incredibly useful as a first-line eval to ensure that what the LLM spits out is sound in terms of data inputs and outputs. Strong static typing is an absolute must for building anything bigger than trivial systems.
I wonder what the future of all three is mode bun and deno, their original goal has always been to be able to code in one language across frontend and backend, and typescript itself is a hell of a good language too.
But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.
I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.
I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).
I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.
I never found Deno compelling enough compared to Node.
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.
Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.
There may be use-cases (and the RFC allows ignoring the SHOULD clause with enough reasoning), but GET does not have a request body as per specification, and a LOT of things drop it because of that (most notably - nginx! Also applies to HAProxy and Apache HTTP server afaik, but also a bunch of load balancers)
Enabling the GET implementation to "accept the request body" would literally be the opposite of fixing it. The broken thing here is your expectation. You are looking for POST (or possibly PUT).
You would be surprised how many technologies expect GET with a body. In practical backend engineering, tools like Elasticsearch, GraphQL, complex query engines, and legacy internal APIs rely on GET with a body every day. Apparently even axios messes up on curl GET requests with a body as mentioned in the associated github issue.
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body.
Technically every http method can have a body? But the specification says the semantics are undefined on get and any compliant implementation is free to ignore it.
It was funny a few years ago, when I had to grade students answering a quiz about web services. There was a question about which components were necessary for a valid GET request. The required answer was a list of 4-5 components, such as the "GET" verb, the URI, the HTTP version, etc.
And it was rather controversial that some listed a body as necessary for a GET request, and doing my research I came to find out that a "request body" was often quite undesirable and perhaps contrary to the RFC standards, and sending a "body" in a GET could result in undefined or unpredictable behavior. But it's all in good fun.
Your "bug-for-bug" compatibility ensures Axios, Elasticsearch, many GraphQL implementations, etc. works. Hence I will use node as mentioned in my original comment.
A body is technically allowed on any http request but it doesn’t mean anything on a get, a server is free to ignore it, anything in the middle is free to strip it, etc.
haha! Speak for yourself, but software never judges you or cancels on you at the last minute when you're supposed to meet up at the bar. "Friends," sheesh! :)
I helped Deno bring the Standard Library to v1 [as a contractor] and have always loved the team and philosophy. But these days I’m saddened by what seems to be their slow decline into obscurity. After the layoffs, there seems to be no roadmap, no comms, etc. I’m just so curious as to where they’re heading and still hope the best for it. I’ve always liked Deno more than Node and Bun.
The saddest part is that there have surely been acquisition offers from bigger players that they declined, but given how strongly the market favors the hyperscalers and super-capitalized AI companies an acquisition might’ve been their only sensible play. You either sell or get squeezed out.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.
Bad news (well not news, this happened a while ago): https://www.cnbc.com/amp/2020/03/16/microsoft-github-agrees-...
Don't worry. I'm sure Microsoft will be as good of a steward of npm and its ecosystem as they have been for GitHub.
GH still has its own login system thankfully, and I can't even sign in with Microsoft or link my Linkedin profile in any way (at least from Github.com; I'm sure there's a public Linkedin-developed Github App). I'll take what I can get.
The article is from 2020, so you may already be able to make that judgment.
They've been a great steward of GitHub. You people have no perspective. They've kept an insanely generous free tier - free private repos, free CI runners including windows and Mac! And no ads.
Name one other company that would do that.
Deno is still an easy pick for me because of its built-in test-runner (deno test), linter (deno lint), and type checker (deno check). I've used many different npm packages for these things in previous projects and I have no idea what the new hotness and proper configuration is for all of these things in a new node project, so I really value the simplicity of Deno for it all. Also JSR and Deno for publishing Typescript libraries is still so much easier than setting up a Typescript node project and configuring it to publish compiled code, and it gets you documentation pages generated from your tsdoc comments too, which I never knew how to do outside of JSR.
The new hot lint (for me) is Oxlint. Literally a 300x speed improvement on our monorepo compared to eslint for the same ruleset. It’s amazing, especially in combination with Oxfmt instead of prettier.
Well, TBH being better than eslint (especially with the OCD-afflicted prettier) is a really, really low bar...
FWIW Node now has node:test, but yeah you still need dependencies for linting and type checking.
Node.js has a built in test runner and it is excellent. https://nodejs.org/api/test.html
Not sure if the runtime should be responsible for linting of type checking.
The hot shit is still typescript, eslint. I have been using those for more than a decade in node. For me, (deno lint) sounds like the new hot shit.
With LLMs becoming prevalent, it seems people are “quitting” their projects more quickly. Not necessarily a bad thing, but just shows that the opportunity cost is too high right now if you’re building the wrong thing. Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
> Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.
This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.
LLMs don't reach for it because the frontier companies don't have it as the default. I've instructed Claude to NOT use React (use SvelteKit), NOT use Node (use Deno or Bun), among other things.
The industry defaults are trash but it is what it is.
They would rather have some unreadable python scripts and vendoring than using a package manager in a c++ project...
It also really really wants to use Gradle if you're making a Bukkit plugin, even though you really only need the JDK.
Oh man they all reach for the nextjs dumpster fire. Every single vibe coded app is that stack. At least many are backed with supabase (Postgres is a same choice).
> LLMs don’t reach for it
Please excuse my language, but that's only the case if you're a complete imbecile and can't write a for loop to save your life.
An LLM doesn't "reach" for anything, because you tell it what to do. You go "use this tool, to do that thing, in this way, here's a bunch of written guidance on how exactly to do that, and if you run into issues ask me". Any other use is glorified copy-paste slop code and will end up with a worse codebase than if you let an egomaniac run amok on a single codebase for 20 years.
This is part of how LLMs are hurting progress. People are moved away from things like StackOverflow or new projects where they pose and answer questions with real people, or create novel things, and pushed more and more to whatever answers or solutions the LLMs will spit out for them.
Shouldn't be an issue. Like LLMs don't reach for uv, but they will if you make it clear you want to use uv.
I added a wrapper script around Deno to my agent’s allowlist to take advantage of its permissions system, and instructed it to use Deno instead of Python or bash commands. It’s worked pretty well.
"Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now"
Well, in my case I suddenly had deno installed, while letting run fable in auto mode, even node was already there and I had to look up what deno was. "Ah, that node replacement."
Turns out the 'boring enterprise runtime' spent its time actually shipping stability while everyone else was chasing the next shiny runtime hype cycle.
It's great that they developed alternatives to Node, I was just getting annoyed with all the users trying to bait in more users like "why don't you use [Deno/Bun], it's completely compatible" when it's not. Same with all the Python interpreters besides CPython.
Many such cases.
I know Bun is kinda not the fan favorite right now with the Anthropic acquisition and the Rust re-write drama and such, but on every one of the dimensions listed in this article, I like Bun better than either Node or Deno.
The author gives his (non-technical) reason for not using bun here:
https://dbushell.com/notes/2025-09-10T12:08Z/
without having the full background here. This feels like a very valid reason
I use bun for the sole reason of it running perfectly on riscv64, while void zero is sleeping and not providing vite/tsdown/oxwhatver builds for it.
Bun is awesome. It feels great these days to start with bun or convert a nodejs app over and reduce deps down, sometimes to 0.
Ive just gone all in, no more mega bash scripts that constantly bug out on the silliest problems whenever you try to do anything complex involving a list data type.
It just feels like its something you can pretty much always bend towards what you need without needing to breakout into another language and I'm keen to see some of the new performance stuff their continuing to work on.
I'm building on Deno for the past 2 years and I have no regrets. It still delivers me why I picked it over node. Less config, less packages to install, good DX.
Oh, I always thought this was the blog of someone that had spent a lot of time developing using DBUS
anything but bun?
As a casual both Bun and Deno user, I have generally preferred Bun to Deno unless sandboxing is a concern.
I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.
Nothing says “mature ecosystem” like migrating to a different runtime every few years.
I am not sure about deno not being innovative - I've recently started using deno for it's new desktop app support only (https://docs.deno.com/runtime/desktop/)
this is being innovative? nevermind, not gonna argue on that
but some AI projects have been using deno desktop to run python via pyodide locally, I couldn't complain since it's like a sandbox to them
Oh look, we’re consolidating again. My only gripe with it was that it wouldn’t directly run Typescript. Other than that it just felt a little ... antiquated.
Bun seems popular too, what would be reasons to choose it?
The only reason to choose Node is because it's boring, is a long lived project and I think it will outlive Bun and Deno.
Bun is much much more lighter than node or deno. If you don't mind the controversy around the rust rewrite, it's objectively the better option in most cases.
A month before the rewrite I was hitting soundness bugs on fairly trivial JS code. I remember right, under HMR re-exports of module variables caused a snapshot, and importers of the reexport saw stale values.
I reported it, watched robobun write an unhinged +300 -0 patch which quickly got LGTM'd and merged.
I hope now that we've moved past AGI and into the ASI era things are better.
I made a fairly straight forward webapp with Bun and let Claude check whether it was actually better than Node. Nope, Node consumed less memory and used about the same CPU as Bun. I didn't switch, because it costs tokens, but Node's reputation seem to be based on its legacy more than on today's use.
This is making me feel 1337 for being too lazy to even consider leaving Node. Same thing with Log4j vs System.out.println.
> Why? Just strip the types bro, I know you can! Let me sign a deal with the devil!
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).
> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.
The TypeScript compiler itself comes with everything you need for this. See: https://www.typescriptlang.org/tsconfig/#declaration
There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.
> A mismatch would mean you would get type errors inside the library code
OP doesn't want the types to be checked, they want the types to be stripped. Type stripping ignores tsconfig.json files and any of its features, see: https://nodejs.org/api/typescript.html#type-stripping
Yes, but your TypeScript code has to be checked against the libraries in node_modules, and it is significantly costlier to check against implementation files (the .ts/.mts files) than the produced declaration files (the .d.ts files).
Sure, that's all correct, of course a performance hit would be noticeable if thousands of dependencies would need to be checked additionally.
OP is talking about type stripping nonetheless, and I'd put type stripping into the same ballpark as reading ambient declarations, performance wise.
Type stripping cannot ignore tsconfig.
TypeScript has different semantics depending on settings in tsconfig e.g. useDefineForClassFields
Type stripping can and does ignore tsconfig.json files, from the provided link:
> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.
Of course import aliases and such features would break.
I wanted Deno to succeed to have a single standardised toolchain, but with Deno having its own APIs you'd effectively have to architect your application to be a "Deno app" and it created two different ecosystems. The best way to make your app portable would be to use the provided Node APIs, cutting a lot of the value from Deno.
I never left node.
The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.
I'm curious though: for people still choosing Deno today, what is the one thing Node still doesn't give you?
Sandboxing and being more aligned with web standards, though admittedly on the latter I haven't checked back in on node with to see if there's been a push towards having the same tools as the browser engines instead of import('garys-crypto') etc
Security, as outlined by OP?
I reluctantly do anything with JS/TS but if I have to, I'll pick Deno because I'm sick of needing to install a dozen dependencies which then require their own thousands of dependencies.
Even if I pick modern tooling, say Biome for linting and formatting, Vite for bundling and handling the build, Vitest for unit testing, and finally TypeScript.
Once that's done, it's then remembering the right values needed in package.json and tsconfig.json to do the right thing and Just Work TM. It's 2026 and all this slop still assumes I don't want ES modules.
I could spend a whole morning on this bullshit. With Deno, I don't have to.
I always contrast that with my preferred languages, like C#/.NET. Project setup takes literally a few minutes. Deno and .NET have that in common, there is a single CLI for it.
The Deno JSR/STD thing also has a whole collection of libraries and data structures I'd otherwise need to get from NPM.
There are good reasons to stay positive about deno. Some of them: https://lobste.rs/s/a9kwzv/friendship_ended_with_deno_now_no...
> There is no reason to use the Deno runtime today.
LMAO okay bro.
With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.
+ deno's file-system permission model is the answer to recent malicious npm packages fiasco:
"deny access to ~/.ssh and other important folders" --> that alone would likely have 99.99999% sterilized most "hacks"
I want to run my node project on Deno for performance testing, but Deno has problems when executing OpenSSL in a child process.
It's great that we now have 3 major JS server environments: Node.js, Deno and Bun. The competition keeps them all in check.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.
TypeScript is, objectively, the superior option—especially in the presence of LLMs, because the type safety is incredibly useful as a first-line eval to ensure that what the LLM spits out is sound in terms of data inputs and outputs. Strong static typing is an absolute must for building anything bigger than trivial systems.
I wonder what the future of all three is mode bun and deno, their original goal has always been to be able to code in one language across frontend and backend, and typescript itself is a hell of a good language too.
But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.
I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.
I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).
I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.
I'm hoping now this is the end of this guys constant hate posting about Deno. What a negativity fountain.
Love the site!
Title origin: https://knowyourmeme.com/memes/friendship-ended-with-mudasir
Thank you! Never researched it before. It's a pretty wholesome story that he ended up with two friends.
I never found Deno compelling enough compared to Node.
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.
Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.
You shouldn't be sending a body with a GET request. Sounds like your code is broken.
No. There are use cases for GET with body. Curl allows it. Node allows it. Bun doesn't.
There may be use-cases (and the RFC allows ignoring the SHOULD clause with enough reasoning), but GET does not have a request body as per specification, and a LOT of things drop it because of that (most notably - nginx! Also applies to HAProxy and Apache HTTP server afaik, but also a bunch of load balancers)
no.
Wrong.
Hint: Elasticsearch, GraphQL, Axios, etc..
GraphQL uses POST for queries.
Many GraphQL clients/libraries use GET with body to workaround hitting URL query limitations like length, etc.
Spec is not the same as compatibility.
Enabling the GET implementation to "accept the request body" would literally be the opposite of fixing it. The broken thing here is your expectation. You are looking for POST (or possibly PUT).
You would be surprised how many technologies expect GET with a body. In practical backend engineering, tools like Elasticsearch, GraphQL, complex query engines, and legacy internal APIs rely on GET with a body every day. Apparently even axios messes up on curl GET requests with a body as mentioned in the associated github issue.
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body.
A request body in a GET is not standard HTTP. Refusing to handle non-standard requests might be inconvenient, but it's an eminently defensible choice.
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
QUERY, added in 2026, does not resolve existing or legacy applications.
Sticking to RFC is one thing. Advertising as node compatible is completely different altogether. Many people cannot see the difference.
Atleast a flag would suffice as that would ensure existing infrastructure tooling doesn't break while keeping the RFC spec folks happy.
Technically every http method can have a body? But the specification says the semantics are undefined on get and any compliant implementation is free to ignore it.
It was funny a few years ago, when I had to grade students answering a quiz about web services. There was a question about which components were necessary for a valid GET request. The required answer was a list of 4-5 components, such as the "GET" verb, the URI, the HTTP version, etc.
And it was rather controversial that some listed a body as necessary for a GET request, and doing my research I came to find out that a "request body" was often quite undesirable and perhaps contrary to the RFC standards, and sending a "body" in a GET could result in undefined or unpredictable behavior. But it's all in good fun.
They just implement the fetch api from the web, does the fetch api allow get’s to have a body?
Node allows it. Curl allows. Not having it is a breaking change and undesirable for node compatibility.
If you need bug-for-bug node compatibility you should be using node.
Your "bug-for-bug" compatibility ensures Axios, Elasticsearch, many GraphQL implementations, etc. works. Hence I will use node as mentioned in my original comment.
You should use bun :)
A body is technically allowed on any http request but it doesn’t mean anything on a get, a server is free to ignore it, anything in the middle is free to strip it, etc.
You need better friends
haha! Speak for yourself, but software never judges you or cancels on you at the last minute when you're supposed to meet up at the bar. "Friends," sheesh! :)
It's going to be a negative feedback loop
1. people choosing the ai companion for the frictionless relationship
2. people losing the skills needed for real life human relatioships
Node is really good, and whatever thing that comes out outside of it will eventually be engulfed by it. Node is the safe bet :).
if you want to try a new runtime oam.js is focused on TypeScript & MCP servers.