So the move away from Deno has a long history. A bit of context, for those who are interested:
The very first prototypes of SilverBullet were built on node.js as backend, and built the frontend with node.js-tooling as well. Then I had this idea of allowing for a sandboxed plugin mechanism where plugins could transparently either be run in the browser (in an iframe or webworker) or on the server. I managed to get this to work on the server somewhat with node, but it was clear that node was not really designed with much server-side sandboxing support.
Deno was about to hit 1.0-ish around this time, and I liked it a lot. Node "done right" from the same original author as node, and their CTO (Bert) that I actually knew from a previous company, all built on Rust! Some sort of limited permission support for workers. Great!
And for many years it was a reasonable choice. However, it's also been a source of intermediate frustration. The Deno team moves fast and sometimes breaks things, and over the years I've had to report various regressions. They were quickly fixed, but still a distraction. They've changed tactics quite a lot on package management (HTTP imports, import maps, JSR, varying levels of supporting npm) that resulted in unwanted churn trying to just stay things up to date with the latest best practices. Then there were a bunch of cool features like Deno KV that started out very promising, but were not very deeply developed. Sometimes seemingly abandoned.
Since Deno is a VC-backed company, from a long-term thinking perspective, with my "CTO hat" on it's always been a bit of a gamble to build on such technology if the business model has not proven yet. A few years later, I think it's still not been proven, and in fact the recent lay-off at Deno doesn't instill much confidence that they've hit that part out of the park yet. So for me, the long-term future of Deno is unclear.
At the same time, a few things happend:
Node.js has started to catch up on support of various APIs (probably under pressure from Deno and Bun), like fetch and others, and there may be typescript (ish) support there at some point.
The other development is that as of SilverBullet v2, the need for a back-end in SilverBullet is almost symbolic. I rewrote the remaining backend from Deno to Go in a few days, and now have another implementation in Rust that lives in SilverBullet+. There's not much there.
As @MrMugame said, in terms of maturity of toolchains, there's a lot of difference. Deno comes with a bunch of nice things out of the box (like fmt, lint etc.) but the Node ecosystem is much richer. Given that I only really have the client (frontend) to care about now, SilverBullet gets almost 0 value out anything specific that Deno offers. It is however a barrier to entry in terms of onboarding new people, because a lot more people know node/npm than know Deno.
That's why a few months ago I decided I'd slowly step away from the Deno dependency and a release or two back that finally happened. Building plugs this way is part of that.