Hacker News

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

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.

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.)

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.

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.

FWIW Node now has node:test, but yeah you still need dependencies for linting and type checking.

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.

> 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.

node!=npm, and microsoft doesn't own the development of node.

> Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.

This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.

LLMs don't reach for it because the frontier companies don't have it as the default. I've instructed Claude to NOT use React (use SvelteKit), NOT use Node (use Deno or Bun), among other things.

The industry defaults are trash but it is what it is.

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.

> 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.

"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 agree. I don't think this is anything to sneer at.

The author gives his (non-technical) reason for not using bun here:

https://dbushell.com/notes/2025-09-10T12:08Z/

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.

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.

It's great that they developed alternatives to Node, I was just getting annoyed with all the users trying to bait in more users like "why don't you use [Deno/Bun], it's completely compatible" when it's not. Same with all the Python interpreters besides CPython.

Many such cases.

I'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?

(ironically) OP is from the UK, so would be geoblocked by imgur

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?

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

Bun’s BFFI is very similar to Deno’s FFI. I believe the approach originated in LuaJIT.

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.

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 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

nvm is not node. and there are better options for managing node versions (eg mise).

How do you switch Deno versions on Debian?

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.

> instead of striping types

That's what Deno does too, tho. Typescript is designed to work that way.

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.

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.

Linguistically promiscuous omniglot.

I just learned that Bun is made by fascism-lovers: https://news.ycombinator.com/item?id=49971719#49973992

+ 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"

So glad I have my backend on the JVM and in Kotlin.

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.

You shouldn't be sending a body with a GET request. Sounds like your code is broken.

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).

They just implement the fetch api from the web, does the fetch api allow get’s to have a body?

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"?

Same, I came for the dbus hell, stayed for the ...

lol, I made the same comment the last time this website was shared here.

Thank you! Never researched it before. It's a pretty wholesome story that he ended up with two friends.

Yes, obviously their lives don't matter anymore.

On a serious note, I thought only expressjs had it?

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! :)