Deno's Decline

I really want to like Deno. I started to watch &quot;just a few minutes&quot; of their keynote (I assume it was the most recent one, this was a month or so ago) and was intrigued by it and ended up watching the whole thing.<p>Then I went to go play with it add... I ran into odd compatibility issues (no, I don&#x27;t remember them, I&#x27;m sorry) and tried Bun and everything &quot;just worked&quot;. I&#x27;m sure Bun is not perfect but so far, every one-off script I&#x27;ve thrown at it has &quot;just worked&quot; which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be.<p>If I never see an error about how I should change my &quot;type&quot; to &quot;module&quot; only to do it have it complain about 10 other things I will die happy.<p>I love Javascript, I love TypeScript, I feel like I&#x27;m primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K&#x2F;V store ring very true. I kept looking for things like &quot;What backend framework should I use?&quot; and the answers were all over the place and not very mature options. It felt like I was building on sand.<p>I hope I&#x27;m 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.

I use Deno all the time... but it might not be exactly how it&#x27;s marketed...<p>Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno.<p>It&#x27;s like a glue language for me at this point. I don&#x27;t need to focus on configuration or any setup like this - I just create a new dir and I&#x27;m off.<p>This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it&#x27;s ecosystem like Postgres and Redis (which both had a release within the last week).

That&#x27;s sad to see.<p>&gt; If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled.<p>I don&#x27;t agree with the author&#x27;s use of &quot;rug pulled&quot; here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun.<p>Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.

Alternatively, this may be Deno’s “Dip”: A tough period of time before continued gains and small breakthroughs that build up over time to a new plateau. Maybe all new creative projects will have this as a part of their journey. I am confident Ryan Dahl is unlikely to give up, and is aware (and working to become more aware) of what is necessary to improve for deno to achieve the vision he has for it.

I loved David Bushell&#x27;s writing. Very entertaining as always.<p>I do agree many of Deno&#x27;s products are in decline.<p>But I think deno is by far the superior typescript&#x2F;javascript runtime. And deno can be run on many reputable edge providers. So deno deploy is not necessary. It&#x27;s too bad because I did like the simplicity of deno deploy, but other edge provides seem to be good too.<p>Some of it does indeed need tweaking to get it work. But I find many amazing pieces of software written for Deno. And I find deno&#x27;s tooling and security way more mature than node or bun.<p>As long as the tooling stays good and the runtime is updated. I&#x27;m staying.<p>I will be willing to switch to bun if the tooling&#x2F;security gets good. I should revisit bun to see if it is now good. To my knowledge bun does not have granular permission levels like Deno. I don&#x27;t understand why the runtime should have access to everything by default. I much prefer deno&#x27;s way of doing things.

The rust reimplementation of the node modules is interesting to read. I took some ideas for the llrt runtime modules. As a comparison Bun Zig implementation is scarily ignoring a lot of edge cases.

One major reason I still haven&#x27;t switched away from Node and NPM is <i>major</i> stability and support, pretty much everywhere, e.g. full automatic VS Code support. Plus, even if it&#x27;s ever so slowly, Node.js is legitimately keeping up to date with the latest ES features and always improving its stdlib, and V8 is still the king of performance and likely to remain so, unless, say, a court were to split up Chrome from Google funding by monopoly laws. That said, Node progress is <i>slow</i>. I&#x27;m not entirely sure why. I&#x27;d be glad to get paid to help make Node.js better if that were a job. And I&#x27;m still waiting on #57696 to avoid using async in a few places that I otherwise wouldn&#x27;t need to.

I don&#x27;t intent this to be mean to Deno, but did it ever really get traction? Hard to describe something as a decline if it never really held a significant position.

At first I thought this was from a site called &quot;DBUS Hell&quot; and I was excited to read war stories about building the Linux desktop.

i use deno all day every day.<p>it’s really about taste. deno has insanely high standards, and the choices they make are great.<p>deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity.<p>if you’re looking at node and think it’s great, you should use it.<p>node compat makes me like deno more, not less.<p>it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.

I wired up some custom middleware on Bunny using Deno and it was the first time I really saw the value of it. It was really nice to just hot load dependencies via a URL, write my code, and go. Beyond that use case, though, not much has stood out.

Deno is great!<p>I am trying to use it as a FaaS to some level of success<p>I only wish that the compiled binary retain full Deno capabilities, it would be even better if the permission model could limit file system access and limit cmd to a specific user<p>I&#x27;ve also been using Deno Deploy for AI integrations, and something I miss is being able to have multy-file projects without deploying from github<p>Just give me a online vscode environment, limited as it may be<p>Typescript LSP should be able to run in a worker, and I wouldn&#x27;t mind having to install a browser extension if necessary

This is sad news. I always found NodeJS&#x27; APIs to be a bit deficient, and liked Deno&#x27;s better - with the caveat that they openly admit to copying designs from Go[1], so it&#x27;s not necessarily original.<p>[1]: <a href="https:&#x2F;&#x2F;deno.land&#x2F;std@0.164.0" rel="nofollow">https:&#x2F;&#x2F;deno.land&#x2F;std@0.164.0</a>

Meh, I worked at Deno until last year and I think the signal of seeing Deploy downsize regions is not much of anything. The Deploy product itself suffered from some early missteps in terms of design. If anything, scaling down to a few core regions puts them in a better position to rebuild a stronger offering.<p>There wasn&#x27;t really a rugpull in the <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a> dependency space either. It just turns out that the package approach for software is better and there are major unsolved problems in web-identifier-based code distribution.<p>I was skeptical of the value of JSR when it was first internally announced but TBH, but I think it&#x27;s a strong offering in the packaging space and is in a better position than alternatives.<p>node.js compat is hard, packaging is hard, writing performant Rust&#x2F;V8 hybrid code is hard, but the team is pretty packed with smart people who really understand the space.

IMO in JS&#x2F;TS world its atm Bun vs. Deno in replacing node, npm, pnpm, yarn whatever other package manager. What i see is, that Deno try to go the vercel way and want to make some money to finance all this open source development. IMO totally legit. And also, normal, when you spin up a (startup) idea, 19 of 20 will fail. So i don&#x27;t get the point of the article actually. The Article points to all this ideas but forgets that deno&#x27;s core is the runtime. In between the lines, a node &#x2F; LAMP-Stack history blinks up.

I like deno&#x27;s security model where you have to enable things. But I think it made a HUGE mistake to the point of being useless.<p>Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled.<p>The issue we face is making sure our <i>dependencies</i> don&#x27;t do something nefarious. Demo doesn&#x27;t solve that. I would really, really like to be able to specify these flags at the package level.

I&#x27;m not convinced. The author has had a pretty negative view of Deno, JSR, etc since the beginning.

Sorry for putting the security hat, but how does anyone run Deno in production without any worries when this is the state of affairs of their vulnerability notifications and scanning. No SBOM &#x2F; SCA tool that I know of supports deno.lock and since it has a distributed nature, as far as I understand there is basically no way to be alerted on CVEs, unless you work hard to generate a compatible package-lock.json &#x2F; yarn.lock file and stay with only npm compatible packages etc. Is it bothering only me?<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Deno&#x2F;comments&#x2F;1g5mu0l&#x2F;thats_all_good_but_whats_with_audit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Deno&#x2F;comments&#x2F;1g5mu0l&#x2F;thats_all_goo...</a><p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Deno&#x2F;comments&#x2F;1dpexwv&#x2F;dependency_vulnerability_notifications&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Deno&#x2F;comments&#x2F;1dpexwv&#x2F;dependency_vu...</a>

From hanging around Deno&#x27;s official Discord, Reddit, etc, I get the impression that there are simply not that many people using it.<p>I doubt they are making much money from the public-facing Deno Deploy product, and are probably reducing its number of regions because those who are using it are mostly just noodling around on the free tier.

Really liked Deno, particularly its support of url imports. As primarily a Java developer having to deal with Maven dependencies, I cannot stress enough how refreshing it was to just say &quot;the dependency is <i>right there</i>, go get it&quot;.<p>The problem came when I noticed how Deno was being steered towards SaaS. For example, Deno KV, which uses SQLite internally, became available with v1.33 (<a href="https:&#x2F;&#x2F;deno.com&#x2F;blog&#x2F;v1.33#built-in-kv-database" rel="nofollow">https:&#x2F;&#x2F;deno.com&#x2F;blog&#x2F;v1.33#built-in-kv-database</a>). But actual SQLite support did not come until v2.2 (<a href="https:&#x2F;&#x2F;deno.com&#x2F;blog&#x2F;v2.2#support-for-nodesqlite" rel="nofollow">https:&#x2F;&#x2F;deno.com&#x2F;blog&#x2F;v2.2#support-for-nodesqlite</a>) nearly two years later... and it&#x27;s a <i>node api!</i><p>The fact that Deno is lagging behind Node so it can shepherd people towards a first-party alternative that they <i>just so happen</i> to offer premium services for is... well, it didn&#x27;t bode well.<p>I&#x27;ve since abandoned Deno for Bun, which has meant giving up url imports, but Bun always feels so fresh. It gave me first-party SQLite support, not an abstraction around SQLite that they <i>hint hint, nudge nudge</i> me towards paying for. That said, I have felt a little uneasy about Bun since its v1.2 release (<a href="https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;bun-v1.2" rel="nofollow">https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;bun-v1.2</a>).

It&#x27;s kind of funny but also depressing watching all the frontend people try to force Javascript onto the backend. They&#x27;ve been slowly rewriting their tooling using more suitable languages:<p>- esbuild (Go) is 100x faster than webpack and friends<p>- Bun (Zig) and Deno (Rust) are ~2x faster than Node<p>- Typescript recently announced a rewrite in Go for an expected 10x performance gain<p>Maybe one day they&#x27;ll realize that those languages are good for more than developer tooling? Maybe they can even be used for serving web content?

What interests me, are alternatives to Javascript type languages<p>Deno was a step away from the shortcuts Node.js took, Typescript was a step away from the ones Javascript took.<p>But time has moved on. Surely there is space for a *modern* garbage collected language (ie disqualifying Rust) for building servers.<p>I spend my days programming in Typescript, and Rust. Typescript is ancient. (Vaguely Typed Script would be a more accurate name)<p>Is that language Go?<p>Does anybody start major projects using Node&#x2F;[Type|Java]Script anymore?

The article mentions a decline in the number of regions Deno Deploy has in production. It isn&#x27;t criticizing the runtime, but the confusion is understandable since they have similar product names.<p>I wonder if there&#x27;s a reason why there&#x27;s a decline that the Deno people could weigh in on? Perhaps it&#x27;s not a money issue, but some other reason why they decided to scale back the number of regions.

Supabase&#x27;s decision to take a dependency on Deno, IMO caused indirect pain to lot of devs. I have wasted quite a bit of time trying to find or load a package that I needed. And now, with Deno 2.0 apparently everything is node compatible... I don&#x27;t know what was the whole point.

I like the idea behind Deno. I hope the runtime stays relevant.<p>JSR sounded amazing on paper, but in practice, it seemed to have a lot of papercuts. You still can&#x27;t make an account there without a GitHub account, I think.<p>I wish they made a stronger push for its standard library to be used outside Deno. Such a push would clash with their original goal of not depending on npm, I guess. A well-maintained set of common functionality implemented in a cross-runtime way is still needed by the ecosystem, I think.

I get it, there are heaps of NodeJS systems out there. Both Deno &amp; Bun claim to be an improvement over NodeJS and then invest masses of time to be compatible with it.<p>I never liked NodeJS and I would much rather prefer a clean room JS environment with absolutely no explicit NodeJS compatability. 100% support for Web API specs would suffice.<p>Why can&#x27;t Deno or Bun release a slim version and then a compatability preserving version for those folks who require it?

Agree with the author. Deno recently has been loud about Oracle and the JavaScript trademark. Maybe they’re right, maybe they’re wrong, but it is a “last gasp” when your value proposition is something like: choose Deno, we’re righteous.<p>Feels like a tactic to gain some attention. That’s just not how the market typically makes buying decisions, so what’s the value of the distraction when your product is in such a poor state?

I wanted to create webdav servers hosted by glitch and cpanel. I ended up with exactly the same code on both, nice! Basically they both have node.js capabilities so I could use node.js webdav-server.<p>But then I got the bright idea of using deno deploy which I&#x27;ve used in the past and loved, even using kv rather than a file system. It works (thanks chat) but it basically required creating my own version of the node.js webdav-server. Kinda annoying.<p>The bottom line is that deno deploy is fighting a battle it can&#x27;t win. Deno was the &quot;better&quot; node.js. And then it started integrating node capabilities, trying for a drop-in replacement of node. Nope. Sigh. I still love it for many simple projects but there&#x27;s a reason node.js is, er, node.

Many have yet to learn the history of alternative implementations like egcs, IronPython and IronRuby, jpython and jtcl, PyPy, Rubinius,...<p>Most of the time switching is not worth the effort for the few things they do better than the original implementation, and eventually if the features are really relevant enough, the main implementation will end up having them as well.

Issue with deno deploy specifically: they have Deno subhosting but the model is you create an end user script, push it, then can run it.<p>There&#x27;s no concept of &quot;run this once&quot; or eval. So it&#x27;s a very heavy, deploy per run, model of iteration which is not suitable for the main use case of giving end users an editor to iterate with

For me Deno as a technology is great, the development of Fresh has been slow indeed however it is such a clean and effective way to write modern web applications. With KV built-in and deploy you don&#x27;t really need to install anything other than the core fresh dependencies.

Not true that its not updated. They just released Deno 2.3 on the 1st of May.<p>There was no such thing as a Deno rug pull, the author links to the use of http imports which are better used inside a map than directly in a file.<p>Deno is fine and as a technology gets more mature it should get more boring.

My thoughts on deno&#x2F;bun:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43458231">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43458231</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42806304">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42806304</a>

With Microsoft&#x27;s move to port the Typescript compiler to Go, Deno faces an interesting technical challenge. They&#x27;re going to have integrate their Rust code with the Microsoft&#x27;s Go. It will be interesting to see how this is going to play out.

I tried Deno for awhile — the ability to run Jupyter notebooks was a cool idea — but I’ve been Bun-only for around a year now. It’s just significantly faster and easier to use.

I&#x27;m not sure what to make of this article.<p>I&#x27;ve been involved in the JS ecosystem for a very long while and was a very early contributor of node&#x2F;v8&#x2F;crankshaft&#x2F;uv and the other libraries that made JS on the server side possible. Back in the days when Ry pitched it in our Zynga office and everyone but our STG was skeptical about JS on the server side. Fun times.<p>To me, peak JS era was express and koa.js. After that it felt more and more complex with feature fatigue implementations that I don&#x27;t really needed to solve my tasks at hand. Webpack, when it was still pitched at the local NuernbergJS, was also super nice as an idea and as an architecture to bundle things.<p>But after a while I got annoyed by the reinvention cycle. Everything got pretty bloated when it could also not have been, and even when they started as a fresh slim alternative to something else. Some folks being proud of maintaining 100s of micro packages (seriously?) and the whole shitshow with leftpad and the debates in TC39 after it happened kind of threw me away.<p>A couple years ago I gave Go another try and I started gradually to reimplement all the tools and libraries I&#x27;ve built before in it, and I loved the simplicity of it. Coming from an embedded C++ background, Go felt like the middle ground in between C and something VM managed, with lots of opinions that I hated at first.<p>But when you realize it&#x27;s better to have an opinion on something for the sake of convention - even when you don&#x27;t agree with it - than no opinion at all, leading to cluttered glue code everywhere - you start to cherish the ecosystem a lot.<p>In my opinion, when I&#x27;m looking at my production languages that I&#x27;ve used vs the ones I try to avoid as much as possible right now, it always boils down to the standard library and packages it offers.<p>Go&#x27;s success is not because of its opinions and conventions alone (I hate them sometimes) but because of the standard library. In go, pretty much anything you want is either in the core or in golang.org&#x2F;x. The only package we need for production software is cilium&#x27;s ebpf package.<p>And I think that&#x27;s the build ecosystem effect that people experience in zig&#x2F;go&#x2F;bun, but not in deno. Deno at this point is as alien to the JS language ecosystem as JerryScript is, and you could&#x27;ve replaced the underlying language completely, and have the same production efficiency.

Deno 2.3 was released after this article was published. Does this invalidate it?

Someone in a thread here a few months back described webdevs and their constant obsession with changing tooling, frameworks, etc. as &quot;mayflies debating politics&quot; or something to that effect and it has stuck with me since. Do all these new frameworks really have some sort of inherent flaws that require rebuilding everything from the ground up every 5 years or less? Or is it just something inherent in the language&#x2F;web (and&#x2F;or the sorts of people who become webdevs) that causes this phenomenon?<p>Or when JS devs suddenly discover concepts like &quot;serverside rendering&quot; and reinvent PHP and ASP.NET.

I said it back when Deno was released, and I&#x27;ll say it again: I&#x27;m not doing another JavaScript rugpull. Node.js is here to stay, it&#x27;s mature, and if you want performance, leave it behind for Go.<p>It was telling when you saw that basically all of Deno&#x27;s interfaces were inspired by Go.<p>I&#x27;m so glad that as an industry we&#x27;re saying &quot;No,&quot; to all of these JavaScript authors who try to yank entire ecosystems along with them as they go try and monetize their spin-offs.<p>I&#x27;m too busy shipping to care.