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.
celld is very interesting and I've been following Dahl's posts on X about it. But it is not related directly to deno. The celld repo [1] for example suggests that it is 78.5% Rust.
It is much more of a side-quest and it doesn't answer the question: where is deno going?
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.
JavaScript and TypeScript ecosystem is the stage of celebrities and superstars, and Deno goes the way of a boring technology, it had done many things right (ESM, battery included, all in one development tool) but it lost the spotlight. It leads me think about another technology: Unison, which is a head of the time but... not so many people understand it.
I've read OP blog and writings for a time. The one takeaway - for me - is how negative/defensive the writing is. And, I'm not sure why it has to be that way.
---
Node kept doing its thing when Bun, Deno, etc. was all the rage. And I do respect Node team for trying to improve little by little. It's not an ideal runtime but, it is _trying_... and that's a positive story.
This was the point the author lost credibility, IMO:
> 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.
I've done a small amount of work with Node (with JavaScript), and many libraries appear to have TypeScript bindings. It "felt" like there was pressure on me to move to TypeScript. (And, my conclusion at the end of my work with Node was that the next time I do anything significant with it, I would start with TypeScript first.)
This confused me for a minute too, I believe the distinction is whether bindings (.d.ts) are allowed in packages, or the library source itself is in TypeScript (.ts). I agree that NPM should enforce library source uses .js files with .d.ts sidecars.
I think Bun is still all the rage in some areas. For us the fact that it makes it easy to work with compliance, means it's often what we pick in place of Node when we work with typescript. Being able to build an API without using anything but the Bun runtime, the Microsoft Azure and our own internal Node packages makes the NIS2 compliance much less of a burden than if we'd work with Node.
That being said. I don't think anyone in my team considers us a "Bun" team in regards to Typescript, all our internal packages are Node packages as an example.
I don't personally have an opinion on it being owned by Anthropic. It was part of our risk assessment, but it obviously passed.
If compliance is the main deciding factor, wouldn't Deno be a major selling point since its inherently NIS2 compliant out of the box? Security is its primary foundational selling point
curious: given the pace of bun development, lack of LTS/support on older point releases etc, how does it qualify this compliance check assuming I believe you're alluding to fewer deps as the reason for "less burden"?
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.
While I'm at it, I forgot to mention the built-in formatter (deno fmt) is great too. I use Prettier in other projects and it's also great in those projects, but it's tiring that it's yet another dependency to remember to add and configure in a new node project.
Honestly I forget now, as I first played around with it months? years? ago when it was pretty new.
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.
> The new deal shows Microsoft doubling down on the strategy of helping individuals and corporate developers adopt open-source software, despite its heritage of distributing products that cost money
That is.....not the way anyone I know would describe Microsoft's history with the open source movement historically.....
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.
I too would have kept it "free" for the LLM learning corpus and the way to nudge developers towards own cloud services and infrastructure. Github Actions is the first obvious deviation from vendor agnosticism here. If it's about "they didn't make profit maximization at all costs a priority" then I agree.
What are you saying? It's not ok for it to be free because they're using that to encourage people to use their paid services? Uhm no shit.
And your comment about LLMs is even sillier. Not only did they buy it 5 years before LLMs became relevant, but there's nothing stopping anyone other than Microsoft from downloading all of GitHub. Look at grep.app for example.
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.
They were talking from a product/company perspective where if Deno isnât the default runtime that the LLM chooses for you, you tend to fall into obscurity.
Thatâs also probably why bun, supabase and netlify have been seeing so many new users, because (at least in my case and unless instructed otherwise), vibe coded projects had a tendency to push me in that direction.
I have a tech stack that I use and yes I tell AI to use it. But if Iâm starting a new project and AI is doing the scaffolding, Iâll just let it decide what to use. It uses Bun a lot of the times. Many people will just go with what AI chooses, right or not.
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.
Same. The Gradle setup it was making was insanely complicated, then the Gradle-free script I forced it to make was very simple. There's no way I would've used Gradle without the LLM either.
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).
It's not polite to say, but I have noticed a direct correlation between the skill level/knowledge of people I know and the quality of results they get from LLMs.
Heck even in my own usage I get far better results when using them in domains I know vs domains I don't.
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 just throw Deno into my agents file and it gets installed in whatever environment I'm working in.
However, the truth is that writing isomorphic javascript programs in the age of agentic coding is much less important to me than it was a few years ago.
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.
You are ignoring that prompting is fractal all the way down to the scale where the human writes everything by hand.
If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.
"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."
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.
I'm concerned about the Deno team's lack of comms and opaque roadmap, but this post mostly demonstrates the author's lack of awareness of what Deno brings to the table and why it's still a compelling runtime in ways Node is still not.
There are valid reasons to choose both, valid reasons to be concerned about the direction of both, but most of the criticism here doesn't seem worthy of a blog post, let alone making it onto the front page of HN.
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.
> My interest in the Bun JavaScript runtime evaporated when I was informed of Jarred Sumnerâs connection to Peter Thiel.
Ok, he doesn't really explain it in your link, but there's another link in that text ... surely that explains it:
>Anyway, I was recently made aware of Sumnerâs connection to/fandom of Peter Thiel.
WHAT CONNECTION!?!?!? Did Peter Thiel help him murder someone? Invest $100k in his project? Is he friends with his uncle?
Look I think Thiel is a toxic human being too, but he's a major Siliocn Valley figure: you can't ostracize any project with any association with him, so if you're going to avoid using an entire technology, at least have the decency to say what this giant terrible connection is!
Follow up: Thiel gave a (teenage) Summer some $$$ (ironically, the exact amount I guessed at randomly in my previous post!):
>In 2014, Peter Thiel's Thiel Foundation awarded a 19-year-old Jarred Sumner $100,000 along with mentorship.
So Thiel gave Summer, as a young starting entrepeneur, a $100k prize ... can you really fault him for liking Thiel a little after that? Apparently the OP does, and will refuse to use a technology Summer created simply because of it.
I'm saying if I'm a young dev, and I get $100k from a famous VC, I'm going to lean towards being a little bit more positive about him than most people ...
... but that doesn't justify boycotting the young dev and everything he ever makes in the future.
Is there any kind of geeky service that lists the range of political views held by the founders of all popular software products? Otherwise, maybe half the software on my computer was made by fascists, and I don't even know it.
For example, Linux â how fascist, communist, or monarchist is it? I'd also be interested to know which NVIDIA drivers are more supportive of the LGBT communityâthe open-source ones or the proprietary ones?
I had never even thought about this until your comment.
It's useful to know where your software comes from. If something is largely funded by one company, we know it will move in the directions favorable to that company - you can be ready for it to move in a direction that you aren't happy with. If your stance on privacy is "my software should preserve it", perhaps primary developers of that software's association with anti-privacy advocates is worth consideration. This is particularly important in OSS with it's "no guarantees, no warantees, no accountable party" disclaimers - otherwise you might get fucked over when the next release starts doing something you really don't want it to (to extend the example above: e.g. sending all the logs to google or whoever).
Consider it my rpi. I have orange pi rv2 (8GB + 2TB NVME), it's the agentic nest where the harness runs and nfs+dlna archive is hosted. One of the agentic personas has the root. The thing is plugged into the router over Ethernet. It's not the fastest raspberry pi shaped thing on the network, but everything I needed worked without fiddling with FDT and using off-mainline builds. Somehow getting arch port to riscv64 and flashing it to microsd was enough to get things running. It probably even has functioning HDMI, but I'm not sure of that.
I like Bun too, I think its ergonomics are much better. If you are writing a front end you can produce the final output without an external bundled. Similarly if you are working on a backend TS project (less of a problem these days but transpiling TS used to be full of gotchas depending on your dependencies) . You can even just build a single binary to deploy in your container. Useful for command line tools to (they come out a bit big, but for personal use is not an issue)
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.
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.
The ones that actually care about JIT in the box are attractive because of that, thankfully CPython is finally taking having a JIT in the box seriously.
That and other advantages gave them real uses. Some of them had freethreading earlier. Some were just faster. But people overstated how easy it was to switch.
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.
Node has felt fine to me for quite awhile. There was a brief time where it felt a little slow comparatively but it's been mostly ironed out. They tend to address their problems decently fast.
The Internet loves to adopt a new shiny thing, try to convince everybody else it's the right decision because it's the decision they made, and then get quiet about it. (i.e. they went back.)
I've been working on a full-stack JS framework since 2021 (was oss; went private earlier this year) and still remember being asked "are you going to use <Deno|Bun> for this?" My answer was "no" and the why is exactly what you've said here.
All of the drama around Node was just that...drama. It works great, anecdotally keeps getting better, and while it definitely has shortcomings compared to Deno/Bun, I can at least trust that it isn't going away or mere months away from a pivot to curry favor.
I look at Deno/Bun as more supplemental, as-needed tools. I think the best Deno application I saw was on Bunny CDN's custom edge scripting. It was really nice to just hack together a script and know that it was going to pull and cache deps without me having to manage a dev environment. It also just worked out of the box.
Rambling, but I dunno. I kind of wish Ryan Dahl would move back to Node, bringing the wisdom and lessons from his Deno work.
What kills me about Node is the org. They've controlled the Node binary for how many years now ... and for that entire time they have chosen a config format that sucks (JSON with no comments).
WHAT ENGINEER WORTH THEIR SALT DOES NOT WANT TO COMMENT THE CENTRAL CONFIGURATION FILE OF THEIR ENTIRE PROJECT?
You can have comments. If you are talking about the package.json file just create a new property named after your project and put whatever string you want in there.
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/)
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 was impressed by bun from the very beginning, and that continued until I needed to use native GPU calls. I had to switch to Node.js subprocesses.
When comparing Bun and Node.js for my tasks, I keep finding more advantages in Bunâs optimizations. I'll handle GPU processes through BFFI. Node.js is also prone to unstable memory behavior with native processes, so it doesnât make sense to use it as an extra layer.
For those looking for stability, Node.js is definitely the better choice.
>My (ancient) experience with NVM and NPM hasnât been stellar. I heard Fast Node Manager (FNM) was better to switch Node versions. Obviously I roll bleeding-edge but I have client projects that demand stability.
Why would just switching the binary version in path be something deep enough to have a preference?
Honest question, I'm trying to think how can the experience be good or bad in a command that's just "use 3.2". Isn't the whole thing a switch, a state variable and maybe handling the download if there required version isn't available?
Relatedly, if you aren't developing C/C++/Rust packages against Node's FFI (rather than emscripten and wasm these days), why do you need a version manager for Node at all, just use your preferred package manager and stick to auto-upgrades of Node LTS.
(That's one of the things I appreciate about Deno is the "let's just auto-install point upgrades" evergreen mentality and its suggestion that side-by-side versioning is maybe a mistake in the JS world.)
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?
Node directly runs Typescript now, just not inside libraries (for political reasons not technical ones). It's type stripping approach is the strictest compared to Deno/Bun in that you must turn on a bunch of Typescript linting like Isolated Modules and Erasable Syntax Only to get it to work (and not use enums or namespaces). (Which is in line with the strictness suggested by the Type Annotations TC-39 proposal, for what it is worth.)
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.
You know exactly what it means. You're just being a pedantic ass to someone for whom English is not their first language
Ps to the original poster. I screw things like this up in my 2nd language all the time.
"more" and "-er" are sort of redundant. You could say
More light (but this is just awkward - you'd just say lighter).
Much lighter gives an extra degree of lightness than lighter.
Much much lighter even moreso. There's nothing wrong with saying it like this in an informal context like this, but it would generally be better to use words like significantly, vastly, enormously, slightly, a bit, considerably etc to modify the degree of "lighter"
Any LLM could explain the nuances of all of this in much much more detail (this actually makes sense, because detail is not -er).
English is difficult, but dont let that stop you - it is easy to communicate effectively with even a low degree of proficiency, when the other person is acting in good faith.
im not the person who you initially replied to... But surely it is self-evident what they meant by lighter (even if we dont know precisely what they were referring to) - CPU, ram etc... This is something that is always discussed when it comes to node vs bun vs deno
Well, no. It's not self-evident even in your description of why you think it would be. CPU vs RAM is exactly the kind of distinction that I was trying to delineate. I've been benchmarking heavily lately as I'm working on a library, and anything that heavily depends on Crypto slightly favors Node. Bun admittedly does win on most things like JSON serialization & pure request/second throughput. However, it's just not clear cut enough to say that it is "much, much lighter" categorically.
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.
> 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.
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.
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).
If I remember correctly, using nvm on Debian to install the newest version of node silently appended lines to my bashrc. Friends don't silently append lines to my bashrc.
I _still_ prefer Deno over Node but I can't say that will be the reality in the near future. Once TypeScript _just works_ (instead of striping types) and the security improvements land by default, I'll probably switch back.
Alarms started ringing for me when they went for backwards support and focused heavily on that, when Bun was already on that route.
node is a big part of what is wrong in the JS ecosystem, is literally the example of "LLMs actually write better code than the average programmer". Deno on the other hand is striving to make better decisions and try as much as they can to make the right contribution to the ecosystem. I can agree that lately as a company it has lost a bit of direction, but I would rather see NodeJS die than Deno.
Generally, a bunch of batteries included out of the box, in which I don't have to care about installing and configuring a toolchain full of third-party deps in order to do stuff like formatting or CSV imports. (Yes, I'm counting the JSR stdlib when I say this. I did say "third-party." This isn't, and in fact it is intentional about being cross-runtime where possible.)
Not needing to have opinions about the details has been one of the most freeing things when working on a project, even if it now means having a slight opinion about not wanting to use npm anywhere that I don't have to.
I realize at this point Bun offers a lot of overlapping "Node-like but with lots of extra niceties." But I happen to like that this one is actively trying to contribute stuff back to the core ecosystem -- the stdlib, initiatives like WinterCG, infrastructure like JSR (which is open source and at least a little bit more resistant to consolidation relative to npm)... Instead of just trying to extend it with a kitchen sink full of first-party features.
Like others here said, I don't think it's just one thing.
- I replaced a mess of prettier config files, eslint config files, tsconfig files, npm install scripts for all the above plus the typescript eslint config plugin for deno fmt, deno lint, deno check. It's nice to have that all in one place.
- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.
- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.
- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.
> - packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
Node does support this! Although it may depend on exactly you link the packages within a workspace â I use `pnpm` and it Just Worksâ˘. Because NodeJS looks at the resolved symlink to decide whether a project is in `node_modules` or not, if the symlink resolves to a package in the workspace, then NodeJS will do type stripping as normal.
In fairness, the documentation is very unspecific about this, so I just had to try it out and see what happens, but it does work.
I think NodeJS also has coverage these days, although I could be wrong there.
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
Well I don't think Deno or Bun (or Node) does this, but I believe both Deno and Bun have tickets to offer it someday (while Node hates the idea passionately)
...
... a way to document/comment the central project config file (ie. package.json).
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.
If I had to guess Deno has found a nice little hosting business and is trying to be cash flow positive with a skeleton crew. It missed its venture scale opportunity. Similar fate to Meteor, which was purchased by a private equity group and is basically just a hosting business now.
There is literally nothing in that thread which justifies describing the Bun dev as a "fascism-lover". If you're going to start fights about politics (protip: don't do that, it destroys discussion forums), you need to at least be accurate in your criticisms. As it is, you're just slandering the guy.
> 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.
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.
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 don't know what kind of LLMs you're using but mine (Claude) has never once in 6 months got the type incorrect; neither with JavaScript nor TypeScript. So what's the point of type safety if it never gets the type wrong?
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them? Just like I don't want to be distracted thinking about types when I code, I don't want my LLM to be distracted by them either. Also, I don't want to waste time waiting for the transpiler to build. I don't use bundling nowadays - Not necessary if I use plain JS; instead I preload all my frontend libraries and distribute them individually; better for caching and they still download in parallel. I don't have to invalidate the entire bundle cache just because I updated one script.
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
In casual convo, I often hear strong typing conflated with static typing. Its generally fine unless im being pedantic for sport. Typescript has a stronger typing system than javascript, but depending on your audience, some might not consider typescript a strongly typed language because of things like `any`, type assertions, and lack of runtime guarantees to name a few
Structural typing versus nominal typing is another one that often upsets "strong type" fans, because structural typing looks weak (but is still stronger than "no typing").
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).
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.
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.
I can't speak for any of these other technologies, but no part of the GraphQL spec requires GET requests to have bodies. The spec is clear about how to use query strings instead.
As I have noted elsewhere here in this thread, spec saying one thing has nothing to do with how many libraries implement something. If the libraries are critical and provide value, then no matter how much you scream for your adherence to the spec, people will use it and depend on it.
The QUERY method is a step in the right direction but it came too late.
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.
Side note: I parse this domain name as "D-Bus hell", and I expect a rant about how Linux IPC is completely broken, then I remember that this is somebody's blog.
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! :)
In my opinion TypeScript is not a feature. Why? 90% of the benefit of TypeScript can be obtained by using `foo({duck, clock})` pattern. And at 90% of the cost and time. TypeScript, like Java, is beneficial in situations where an error is catastrophic. That is not my situation nor the situation of what 90% of programmers?
So to the bro who wrote the otherwise interesting article I say "Just strip the types bro". You can do it!! You like it? You do it!
[Rant of course, but if you had wasted as much of your life writing types in Java you would probably rant as well. Recipe thinking sigh.]
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.
I dunno, lots of activity around https://celld.dev the last few months. Deno team has been high on my radar more than ever since I discovered it:
https://x.com/rough__sea/status/2105853283617440032
https://youtu.be/G-v1hkQ8Sf8
https://github.com/stars/patcon/lists/awesome-celld
I get the sense that they'd just been brewing things around durable objects, and I'm excited for it coming to fruition
celld is very interesting and I've been following Dahl's posts on X about it. But it is not related directly to deno. The celld repo [1] for example suggests that it is 78.5% Rust.
It is much more of a side-quest and it doesn't answer the question: where is deno going?
1. https://github.com/denoland/celld
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.
JavaScript and TypeScript ecosystem is the stage of celebrities and superstars, and Deno goes the way of a boring technology, it had done many things right (ESM, battery included, all in one development tool) but it lost the spotlight. It leads me think about another technology: Unison, which is a head of the time but... not so many people understand it.
I don't think it loses the spotlight more so that it's just node is just good enough and the cost to switch and learn something new as too high
I've read OP blog and writings for a time. The one takeaway - for me - is how negative/defensive the writing is. And, I'm not sure why it has to be that way.
---
Node kept doing its thing when Bun, Deno, etc. was all the rage. And I do respect Node team for trying to improve little by little. It's not an ideal runtime but, it is _trying_... and that's a positive story.
This was the point the author lost credibility, IMO:
> 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.
I've done a small amount of work with Node (with JavaScript), and many libraries appear to have TypeScript bindings. It "felt" like there was pressure on me to move to TypeScript. (And, my conclusion at the end of my work with Node was that the next time I do anything significant with it, I would start with TypeScript first.)
This confused me for a minute too, I believe the distinction is whether bindings (.d.ts) are allowed in packages, or the library source itself is in TypeScript (.ts). I agree that NPM should enforce library source uses .js files with .d.ts sidecars.
You're a user, not the owner of the Node ecosystem.
I think Bun is still all the rage in some areas. For us the fact that it makes it easy to work with compliance, means it's often what we pick in place of Node when we work with typescript. Being able to build an API without using anything but the Bun runtime, the Microsoft Azure and our own internal Node packages makes the NIS2 compliance much less of a burden than if we'd work with Node.
That being said. I don't think anyone in my team considers us a "Bun" team in regards to Typescript, all our internal packages are Node packages as an example.
I don't personally have an opinion on it being owned by Anthropic. It was part of our risk assessment, but it obviously passed.
If compliance is the main deciding factor, wouldn't Deno be a major selling point since its inherently NIS2 compliant out of the box? Security is its primary foundational selling point
Bun has the same permissive trust model as Node
curious: given the pace of bun development, lack of LTS/support on older point releases etc, how does it qualify this compliance check assuming I believe you're alluding to fewer deps as the reason for "less burden"?
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...
TBH there were lots of npm clones that were âbetter/fasterâ and still npm is pretty much everywhere.
Oxc ecosystem is still impressive.
While I'm at it, I forgot to mention the built-in formatter (deno fmt) is great too. I use Prettier in other projects and it's also great in those projects, but it's tiring that it's yet another dependency to remember to add and configure in a new node project.
FWIW Node now has node:test, but yeah you still need dependencies for linting and type checking.
They made some really terrible, non-standard decisions with node:test though. It's a real letdown for me.
You'd think unit testing would be the most already-solved problem in the world: just copy what Jest, Mocha, Vitest, etc. do ... and you're done.
Instead they left out major features and implemented other features in really strange "why are you reinventing the wheel" ways :(
I haven't used it, so I don't agree or disagree, but I'm curious: what do you think was left out or poorly implemented?
Honestly I forget now, as I first played around with it months? years? ago when it was pretty new.
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
those features a great, but aren't what most of the people doing JS/TS care.
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.
> 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-...
> The new deal shows Microsoft doubling down on the strategy of helping individuals and corporate developers adopt open-source software, despite its heritage of distributing products that cost money
That is.....not the way anyone I know would describe Microsoft's history with the open source movement historically.....
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.
I too would have kept it "free" for the LLM learning corpus and the way to nudge developers towards own cloud services and infrastructure. Github Actions is the first obvious deviation from vendor agnosticism here. If it's about "they didn't make profit maximization at all costs a priority" then I agree.
What are you saying? It's not ok for it to be free because they're using that to encourage people to use their paid services? Uhm no shit.
And your comment about LLMs is even sillier. Not only did they buy it 5 years before LLMs became relevant, but there's nothing stopping anyone other than Microsoft from downloading all of GitHub. Look at grep.app for example.
Yeah man, it's super free! And the paid product even works properly 4 out of 5 weekdays
node!=npm, and microsoft doesn't own the development of node.
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.
They were talking from a product/company perspective where if Deno isnât the default runtime that the LLM chooses for you, you tend to fall into obscurity.
Thatâs also probably why bun, supabase and netlify have been seeing so many new users, because (at least in my case and unless instructed otherwise), vibe coded projects had a tendency to push me in that direction.
I have a tech stack that I use and yes I tell AI to use it. But if Iâm starting a new project and AI is doing the scaffolding, Iâll just let it decide what to use. It uses Bun a lot of the times. Many people will just go with what AI chooses, right or not.
Which stack is that?
I use kotlin for the web, mostly because I like working in kotlin and it lets me share a lot of code with my compose app and server.
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...
HY SvelteKit
It also really really wants to use Gradle if you're making a Bukkit plugin, even though you really only need the JDK.
The only reason to ever touch it, are Android projects. I try to stay Gradle clean as much as possible.
Same. The Gradle setup it was making was insanely complicated, then the Gradle-free script I forced it to make was very simple. There's no way I would've used Gradle without the LLM either.
Kotlin projects too.
Nah, Maven also does the job, and I don't do Kotlin anyway.
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).
I enjoy LLMs as much as the next guy but man, having a baseline of knowledge about coding goes a long way.
It's not polite to say, but I have noticed a direct correlation between the skill level/knowledge of people I know and the quality of results they get from LLMs.
Heck even in my own usage I get far better results when using them in domains I know vs domains I don't.
This take is so cold I can use it to reduce my house's cooling bill.
postgres is a sane choice, I can't type
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.
Also the less you know, the more your solution will be the same as everyone elseâs.
I just throw Deno into my agents file and it gets installed in whatever environment I'm working in.
However, the truth is that writing isomorphic javascript programs in the age of agentic coding is much less important to me than it was a few years ago.
> 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.
You are ignoring that prompting is fractal all the way down to the scale where the human writes everything by hand.
If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.
It is distribution sampling all the way down.
So, yes, literally LLMs ARE reaching for "it".
This brings up the question how much weight these people have, if don't even know what their solution should be based on.
"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."
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.
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.
sounds like you don't know about agent skills yet.
I'm concerned about the Deno team's lack of comms and opaque roadmap, but this post mostly demonstrates the author's lack of awareness of what Deno brings to the table and why it's still a compelling runtime in ways Node is still not.
There are valid reasons to choose both, valid reasons to be concerned about the direction of both, but most of the criticism here doesn't seem worthy of a blog post, let alone making it onto the front page of HN.
> vibe-coding Temu Cloudflare.
this is not fair. given the amount of work going into cell-d which will make an open source self host-able workers platform.
cz at the moment there's nothing comparable to Cloudflare workers.
I agree. I don't think this is anything to sneer at.
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/
Wow, I was enjoying bun up to now. This is pretty insane to see.
He really doesn't though!
> My interest in the Bun JavaScript runtime evaporated when I was informed of Jarred Sumnerâs connection to Peter Thiel.
Ok, he doesn't really explain it in your link, but there's another link in that text ... surely that explains it:
>Anyway, I was recently made aware of Sumnerâs connection to/fandom of Peter Thiel.
WHAT CONNECTION!?!?!? Did Peter Thiel help him murder someone? Invest $100k in his project? Is he friends with his uncle?
Look I think Thiel is a toxic human being too, but he's a major Siliocn Valley figure: you can't ostracize any project with any association with him, so if you're going to avoid using an entire technology, at least have the decency to say what this giant terrible connection is!
Follow up: Thiel gave a (teenage) Summer some $$$ (ironically, the exact amount I guessed at randomly in my previous post!):
>In 2014, Peter Thiel's Thiel Foundation awarded a 19-year-old Jarred Sumner $100,000 along with mentorship.
So Thiel gave Summer, as a young starting entrepeneur, a $100k prize ... can you really fault him for liking Thiel a little after that? Apparently the OP does, and will refuse to use a technology Summer created simply because of it.
Dude, are you trying to justify your ties to an ultra-fascist just because he got paid for it? How disgusting.
I'm saying if I'm a young dev, and I get $100k from a famous VC, I'm going to lean towards being a little bit more positive about him than most people ...
... but that doesn't justify boycotting the young dev and everything he ever makes in the future.
Look at what he posted...
If someone considered Peter Thiel an ultra fascist, wouldn't a great thing to do be to take his money and spend it on... not fascist things?
Is there any kind of geeky service that lists the range of political views held by the founders of all popular software products? Otherwise, maybe half the software on my computer was made by fascists, and I don't even know it.
For example, Linux â how fascist, communist, or monarchist is it? I'd also be interested to know which NVIDIA drivers are more supportive of the LGBT communityâthe open-source ones or the proprietary ones?
I had never even thought about this until your comment.
It's useful to know where your software comes from. If something is largely funded by one company, we know it will move in the directions favorable to that company - you can be ready for it to move in a direction that you aren't happy with. If your stance on privacy is "my software should preserve it", perhaps primary developers of that software's association with anti-privacy advocates is worth consideration. This is particularly important in OSS with it's "no guarantees, no warantees, no accountable party" disclaimers - otherwise you might get fucked over when the next release starts doing something you really don't want it to (to extend the example above: e.g. sending all the logs to google or whoever).
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.
Are you using riscv64 in the cloud or desktop?
i'm very interested in RISC-V and would love to read anything you can provide.
Thanks!
Consider it my rpi. I have orange pi rv2 (8GB + 2TB NVME), it's the agentic nest where the harness runs and nfs+dlna archive is hosted. One of the agentic personas has the root. The thing is plugged into the router over Ethernet. It's not the fastest raspberry pi shaped thing on the network, but everything I needed worked without fiddling with FDT and using off-mainline builds. Somehow getting arch port to riscv64 and flashing it to microsd was enough to get things running. It probably even has functioning HDMI, but I'm not sure of that.
I like Bun too, I think its ergonomics are much better. If you are writing a front end you can produce the final output without an external bundled. Similarly if you are working on a backend TS project (less of a problem these days but transpiling TS used to be full of gotchas depending on your dependencies) . You can even just build a single binary to deploy in your container. Useful for command line tools to (they come out a bit big, but for personal use is not an issue)
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.
Why did you use "mega bash scripts" with Node? That seems completely unrelated to your choice of JavaScript engine.
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.
The ones that actually care about JIT in the box are attractive because of that, thankfully CPython is finally taking having a JIT in the box seriously.
That and other advantages gave them real uses. Some of them had freethreading earlier. Some were just faster. But people overstated how easy it was to switch.
Many such cases.
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.
> even surpassing Deno in places
If youâre trashing Deno, it would be nice to give some examples of where node surpasses it and has not just caught up.
Node has felt fine to me for quite awhile. There was a brief time where it felt a little slow comparatively but it's been mostly ironed out. They tend to address their problems decently fast.
The Internet loves to adopt a new shiny thing, try to convince everybody else it's the right decision because it's the decision they made, and then get quiet about it. (i.e. they went back.)
I've been working on a full-stack JS framework since 2021 (was oss; went private earlier this year) and still remember being asked "are you going to use <Deno|Bun> for this?" My answer was "no" and the why is exactly what you've said here.
All of the drama around Node was just that...drama. It works great, anecdotally keeps getting better, and while it definitely has shortcomings compared to Deno/Bun, I can at least trust that it isn't going away or mere months away from a pivot to curry favor.
I look at Deno/Bun as more supplemental, as-needed tools. I think the best Deno application I saw was on Bunny CDN's custom edge scripting. It was really nice to just hack together a script and know that it was going to pull and cache deps without me having to manage a dev environment. It also just worked out of the box.
Rambling, but I dunno. I kind of wish Ryan Dahl would move back to Node, bringing the wisdom and lessons from his Deno work.
What kills me about Node is the org. They've controlled the Node binary for how many years now ... and for that entire time they have chosen a config format that sucks (JSON with no comments).
WHAT ENGINEER WORTH THEIR SALT DOES NOT WANT TO COMMENT THE CENTRAL CONFIGURATION FILE OF THEIR ENTIRE PROJECT?
You can have comments. If you are talking about the package.json file just create a new property named after your project and put whatever string you want in there.
Itâs good to inform people that this hack exists and can work for some situations, but no, thatâs not âhaving commentsâ. Not even close.
That's a workaround, not a comment.
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.
OP, if you are here, here's how the website looks in an older Firefox: https://i.imgur.com/hYh7Gat.png
(ironically) OP is from the UK, so would be geoblocked by imgur
Fair point - https://i.postimg.cc/LsPQjsmq/222.png
How old is that older Firefox?
It also doesn't work properly if you disable JavaScript. On my phone, I can't scroll.
But why?
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
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.
Oh, I always thought this was the blog of someone that had spent a lot of time developing using DBUS
I was impressed by bun from the very beginning, and that continued until I needed to use native GPU calls. I had to switch to Node.js subprocesses.
When comparing Bun and Node.js for my tasks, I keep finding more advantages in Bunâs optimizations. I'll handle GPU processes through BFFI. Node.js is also prone to unstable memory behavior with native processes, so it doesnât make sense to use it as an extra layer.
For those looking for stability, Node.js is definitely the better choice.
Bunâs BFFI is very similar to Denoâs FFI. I believe the approach originated in LuaJIT.
>My (ancient) experience with NVM and NPM hasnât been stellar. I heard Fast Node Manager (FNM) was better to switch Node versions. Obviously I roll bleeding-edge but I have client projects that demand stability.
Why would just switching the binary version in path be something deep enough to have a preference?
Honest question, I'm trying to think how can the experience be good or bad in a command that's just "use 3.2". Isn't the whole thing a switch, a state variable and maybe handling the download if there required version isn't available?
Relatedly, if you aren't developing C/C++/Rust packages against Node's FFI (rather than emscripten and wasm these days), why do you need a version manager for Node at all, just use your preferred package manager and stick to auto-upgrades of Node LTS.
(That's one of the things I appreciate about Deno is the "let's just auto-install point upgrades" evergreen mentality and its suggestion that side-by-side versioning is maybe a mistake in the JS world.)
nvm added like 3+ seconds to my new shell startup, and one of the maintainers defended it with "so what, how often do you open new terminal windows?"
One thing I've learned about tech is that you can never assume something is too boring for opinions.
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?
Node directly runs Typescript now, just not inside libraries (for political reasons not technical ones). It's type stripping approach is the strictest compared to Deno/Bun in that you must turn on a bunch of Typescript linting like Isolated Modules and Erasable Syntax Only to get it to work (and not use enums or namespaces). (Which is in line with the strictness suggested by the Type Annotations TC-39 proposal, for what it is worth.)
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.
"much much more lighter"? What does that even mean?
You know exactly what it means. You're just being a pedantic ass to someone for whom English is not their first language
Ps to the original poster. I screw things like this up in my 2nd language all the time.
"more" and "-er" are sort of redundant. You could say
More light (but this is just awkward - you'd just say lighter).
Much lighter gives an extra degree of lightness than lighter.
Much much lighter even moreso. There's nothing wrong with saying it like this in an informal context like this, but it would generally be better to use words like significantly, vastly, enormously, slightly, a bit, considerably etc to modify the degree of "lighter"
Any LLM could explain the nuances of all of this in much much more detail (this actually makes sense, because detail is not -er).
English is difficult, but dont let that stop you - it is easy to communicate effectively with even a low degree of proficiency, when the other person is acting in good faith.
No, I am literally asking you what you meant because I don't understand you. Are you talking about runtime memory usage?
im not the person who you initially replied to... But surely it is self-evident what they meant by lighter (even if we dont know precisely what they were referring to) - CPU, ram etc... This is something that is always discussed when it comes to node vs bun vs deno
Well, no. It's not self-evident even in your description of why you think it would be. CPU vs RAM is exactly the kind of distinction that I was trying to delineate. I've been benchmarking heavily lately as I'm working on a library, and anything that heavily depends on Crypto slightly favors Node. Bun admittedly does win on most things like JSON serialization & pure request/second throughput. However, it's just not clear cut enough to say that it is "much, much lighter" categorically.
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.
> 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
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.
That's for running your own code. Not for running other people's code.
I presume you didn't get the "Let me sign a deal with the devil!"-part OP mentioned in TFA then.
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.
If I remember correctly, using nvm on Debian to install the newest version of node silently appended lines to my bashrc. Friends don't silently append lines to my bashrc.
nvm is not node. and there are better options for managing node versions (eg mise).
Or fnm! I use it and it's lives up to the name (it's much faster)
Agreed fnm is much better than nvm. But mise is potentially more compelling bc it can do more than just node.
How do you switch Deno versions on Debian?
This is making me feel 1337 for being too lazy to even consider leaving Node. Same thing with Log4j vs System.out.println.
To me 1337 means being on top of the (hacker) game. Using yesterday's tech is like the opposite of 1337 to me ...
... but then again, I haven't even really used the term "leet" much (let alone spelling it with numbers) since high school.
Yeah that's the thing, 1337 itself is old
I _still_ prefer Deno over Node but I can't say that will be the reality in the near future. Once TypeScript _just works_ (instead of striping types) and the security improvements land by default, I'll probably switch back.
Alarms started ringing for me when they went for backwards support and focused heavily on that, when Bun was already on that route.
Sad but true.
> instead of striping types
That's what Deno does too, tho. Typescript is designed to work that way.
Nodeâs type stripping only handles âerasable syntaxâ:
https://nodejs.org/learn/typescript/run-natively
I meant that Deno supports the full language, including enums and JSX/TSX. Node doesn't, AFAIK.
node is a big part of what is wrong in the JS ecosystem, is literally the example of "LLMs actually write better code than the average programmer". Deno on the other hand is striving to make better decisions and try as much as they can to make the right contribution to the ecosystem. I can agree that lately as a company it has lost a bit of direction, but I would rather see NodeJS die than Deno.
Literally left when deno 2.9 is at its best place it has ever been.
Now just deno install everything and even desktop works amazingly well.
Upvoting because of meme reference.
I'm curious though: for people still choosing Deno today, what is the one thing Node still doesn't give you?
Generally, a bunch of batteries included out of the box, in which I don't have to care about installing and configuring a toolchain full of third-party deps in order to do stuff like formatting or CSV imports. (Yes, I'm counting the JSR stdlib when I say this. I did say "third-party." This isn't, and in fact it is intentional about being cross-runtime where possible.)
Not needing to have opinions about the details has been one of the most freeing things when working on a project, even if it now means having a slight opinion about not wanting to use npm anywhere that I don't have to.
I realize at this point Bun offers a lot of overlapping "Node-like but with lots of extra niceties." But I happen to like that this one is actively trying to contribute stuff back to the core ecosystem -- the stdlib, initiatives like WinterCG, infrastructure like JSR (which is open source and at least a little bit more resistant to consolidation relative to npm)... Instead of just trying to extend it with a kitchen sink full of first-party features.
Like others here said, I don't think it's just one thing.
- I replaced a mess of prettier config files, eslint config files, tsconfig files, npm install scripts for all the above plus the typescript eslint config plugin for deno fmt, deno lint, deno check. It's nice to have that all in one place.
- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.
- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.
- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.
There is no "one thing", there's many things, the top of the list being:
- packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
- a good permissions model for limiting access to system fs, net, etc.
- native WebGPU support (including building a windowed app without a web view)
- desktop gui builds that allow using Chromium embedded or WebView
- built-in linter, benchmark, coverage, etc.
> - packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
Node does support this! Although it may depend on exactly you link the packages within a workspace â I use `pnpm` and it Just Worksâ˘. Because NodeJS looks at the resolved symlink to decide whether a project is in `node_modules` or not, if the symlink resolves to a package in the workspace, then NodeJS will do type stripping as normal.
In fairness, the documentation is very unspecific about this, so I just had to try it out and see what happens, but it does work.
I think NodeJS also has coverage these days, although I could be wrong there.
That must be new. It did not work when I last tested type stripping, earlier this year using pnpm as well. And to be fair bun didn't work either.
Glad if it's working now regardless though, I also see some experimental support for coverage in the docs now.
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?
Well I don't think Deno or Bun (or Node) does this, but I believe both Deno and Bun have tickets to offer it someday (while Node hates the idea passionately) ...
... a way to document/comment the central project config file (ie. package.json).
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...
Why do either?
There are better, much better, choices.
A poster child for popularity!= quality
I want to run my node project on Deno for performance testing, but Deno has problems when executing OpenSSL in a child process.
I have more than one friend.
Linguistically promiscuous omniglot.
If I had to guess Deno has found a nice little hosting business and is trying to be cash flow positive with a skeleton crew. It missed its venture scale opportunity. Similar fate to Meteor, which was purchased by a private equity group and is basically just a hosting business now.
anything but bun?
I just learned that Bun is made by fascism-lovers: https://news.ycombinator.com/item?id=49971719#49973992
There is literally nothing in that thread which justifies describing the Bun dev as a "fascism-lover". If you're going to start fights about politics (protip: don't do that, it destroys discussion forums), you need to at least be accurate in your criticisms. As it is, you're just slandering the guy.
oh my god, why? :(
> 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 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.
Nothing says âmature ecosystemâ like migrating to a different runtime every few years.
So glad I have my backend on the JVM and in Kotlin.
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 don't know what kind of LLMs you're using but mine (Claude) has never once in 6 months got the type incorrect; neither with JavaScript nor TypeScript. So what's the point of type safety if it never gets the type wrong?
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them? Just like I don't want to be distracted thinking about types when I code, I don't want my LLM to be distracted by them either. Also, I don't want to waste time waiting for the transpiler to build. I don't use bundling nowadays - Not necessary if I use plain JS; instead I preload all my frontend libraries and distribute them individually; better for caching and they still download in parallel. I don't have to invalidate the entire bundle cache just because I updated one script.
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
Some of us have the job "get stuff done correctly" though.
> Strong static typing is an absolute must for building anything bigger than trivial systems
I was under the impression that TypeScript is only statically typed, not strongly typed, too. Am I mistaken?
In casual convo, I often hear strong typing conflated with static typing. Its generally fine unless im being pedantic for sport. Typescript has a stronger typing system than javascript, but depending on your audience, some might not consider typescript a strongly typed language because of things like `any`, type assertions, and lack of runtime guarantees to name a few
Structural typing versus nominal typing is another one that often upsets "strong type" fans, because structural typing looks weak (but is still stronger than "no typing").
nvm? fnm? what is this? 1998 ?
get with the program and be awesome with mise
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.
How would you hit URL query limitations when putting your GraphQL query in the POST request's body?
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).
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.
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.
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.
Or any compliant implementation is free to not ignore it like istio/envoy, infrastructure tooling, etc.
What is the use of spec adherence if it leads to unusable/broken applications.
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.
I can't speak for any of these other technologies, but no part of the GraphQL spec requires GET requests to have bodies. The spec is clear about how to use query strings instead.
https://github.com/graphql/graphql-over-http/blob/main/spec/...
As I have noted elsewhere here in this thread, spec saying one thing has nothing to do with how many libraries implement something. If the libraries are critical and provide value, then no matter how much you scream for your adherence to the spec, people will use it and depend on it.
The QUERY method is a step in the right direction but it came too late.
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.
And yet many don't, Istio/Envoy for example. There are enough usable applications that utilize it that ignoring the body comes with a cost.
No Typescript
> Why? Just strip the types bro, I know you can!
Since when is it acceptable to make everyone else un-pollute his code?
I'm hoping now this is the end of this guys constant hate posting about Deno. What a negativity fountain.
Side note: I parse this domain name as "D-Bus hell", and I expect a rant about how Linux IPC is completely broken, then I remember that this is somebody's blog.
D-Bus turned Linux into a hairy ball of microservices that breaks at the most inconvenient moments.
Had to run "dbus-launch" to send this comment.
Wait, it's not? What is it then, "DBU shell"?
David Bushell, its in his banner if you click it.
I was under the impression David just had some strong opinions on dbus.
Same, I came for the dbus hell, stayed for the ...
lol, I made the same comment the last time this website was shared here.
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.
oh wait, Node.Js finally removed 'Black Lives Matter' banner?
Yes, obviously their lives don't matter anymore.
On a serious note, I thought only expressjs had it?
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 :).
Love the site!
if you want to try a new runtime oam.js is focused on TypeScript & MCP servers.
"Just strip the types bro"
In my opinion TypeScript is not a feature. Why? 90% of the benefit of TypeScript can be obtained by using `foo({duck, clock})` pattern. And at 90% of the cost and time. TypeScript, like Java, is beneficial in situations where an error is catastrophic. That is not my situation nor the situation of what 90% of programmers?
So to the bro who wrote the otherwise interesting article I say "Just strip the types bro". You can do it!! You like it? You do it!
[Rant of course, but if you had wasted as much of your life writing types in Java you would probably rant as well. Recipe thinking sigh.]
> "whatâs left are tweeting AI fantasies and vibe-coding Temu Cloudflare"
sick burn. can't say i disagree though.