← Back to context

Comment by binlog

10 hours ago

This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.

You can migrate off deno in a single day. It's not a big deal.

  • Exactly that. I am really surprised by the amount of comments with this huge sentiment and doom mongering. These days it’s really not a big deal. Million lines of deno based ts is not a problem because pretty much any functionality provided to deno is available for node as well. You probably can migrate off much of the external deps without much hassle. You can even migrate to different language ecosystem altogether like others have mentioned in comments.

    • > ...pretty much any functionality provided to deno is available for node as well.

      Unfortunately Node still can't do something like this out of the box (AFAIK at least):

          import { Bla } from "npm:bla@^5";
      

      Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.

      Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.

      8 replies →

  • It's one of those things that the technical aspect is simple but the paperwork dehumanizes me. Just a couple more bullshit engineering design documents to generate

  • Node only has experimental permissions support (making it not as good for local scripts), and no WebGPU (though you can import dawn wrapper). Deno desktop is way ahead of anything available for Node.

  • Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.

Exactly why any company that cares about long term maintenance should stick with Node.js except in cases that justify alternative runtime.

I wouldn't be surprised if Bun is abandoned at some point as well.

(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)

I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.

Well, the license Deno is distributed under explicitly warns you (sorry for all caps):

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

I went all-in with bun. Did I bet wrong?

  • What did it get you?

    For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.

    So I never had much interest in looking into benefits of Deno or bun.

    • As a former bun user, speed.

      However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.

      2 replies →

    • As a non-js developer, Bun compiles my ts code to local executables nicely. Allows me to experiment with the new diversity of ts frameworks and distribute the binaries (hobby scope).

      1 reply →

    • I mean I used to do a lot of things I'm glad I don't have to anymore. I'm not a big fan of doing repetitive work just because I understand how to.

      Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.

      9 replies →

  • Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.

    • "we know the extents they go to protect their competitive advantage"

      I don't. What do you mean?

  • Bun always seemed weird because they decided to build it with Zig. I want Zig to succeed, but it's not stable yet.

    It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.

    It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.

How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.

  • I lead a project built on Deno; it was not my call, just to be clear. Deno turned out unfortunately to be a miss and we had seen the writing on the wall. FWIW, we're moving to a much bigger Rust core program with node for JS user extensibility. (In other words, I'm not willing to risk using the deno_core crates.)

    The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.

  • Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.

    Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.

At least open source gives them an opportunity for the community to find a way to support it going forward. But I suppose that's just table stakes these days.

Anybody who has been bitten by the many issue with Yarn over the years can tell you, just stick with stock tools and deal with it.

  • I dunno, we've been using pnpm for years now without issue, and it's been faster and a little more secure to boot!

It's why I usually look more closely at the comments here than at the story for stories like this.

I was really surprised that cloudflare was acquiring deno to be honest, I have written about this here before, Deno was always sort of dead to me due to how little they cared for compat of all kinds (nodejs, CJS, backwards). It was refreshing to see bun care a lot about it (well, now its on a different path in other ways).

Then I read that paragraph, and it made more sense that they're acquihiring + killing.

>So many companies went all-in on Deno in recent years.

Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?

Do they also do their front-end in Dart?

  • For me Deno has a really nice security posture, the permissions model is just something I haven't seen in from other runtimes (JS or otherwise). There were other nice features (native typescript support, compilation to a standalone binary), but the permissions model was just unique.

    https://docs.deno.com/runtime/fundamentals/security/

  • Like a decade ago I got into a huge fight with a Staff Eng at our company over Dart. I had just been put in charge of the company's architecture and one of the first things I did was migrate everything to TypeScript (which was relatively new at the time). He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).

    • I don't know enough about Angular 2 to know exactly how much of a bad choice that was, but my experience in React has always been "they should have used something else". I vaguely recall our lead backend being unhappy with his decision to do the original admin panel in Angular, but I chalked that up to him not being a frontender.

      For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.

    • > though picking Angular 2 over React not so much

      It sounds like you're coming at this from a perspective of popularity and thus access to engineering candidates with expertise in it which is fair, but speaking as someone who also went with Angular 2 over React during those times, I'm still using Angular and I'm very happy with it from a technical perspective. Yes, it does mean there are less options for hiring, but it has been a positive experience for my team and for me in my own projects to stick with it.

    • It's really a bummer that Dart gets a bad rap, because of its early versions. The recent versions of Dart are a lovely language to work with. Pub is the only package manager I've used that approaches Cargo in quality.

      2 replies →

    • My dart story. While in college for computer programming our professor telling us if we wanted to get ahead of the curve start learning dart. It was the future

    • > He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).

      1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.

      2 replies →

  • well Deno was the only player who could have prevented recent npm security disasters:

    built-in permission system for filesystems and etc

    just forbid writing to important folders like ~/.ssh

  • But it is Open Source, so if said companies like Deno enough, all they have to do is pay for its continued maintenance and development. This is one major thing that sets Open Source apart from proprietary software.

  • > Do they also do their front-end in Dart?

    Hey, you jest, but Flutter has a lot of traction!

    (I conceptually like Flutter, but I can't get over the Dart thing, so I'm not part of that traction.)

  • > Do they also do their front-end in Dart?

    This is actually a good decision though.

  • > Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?

    Wait till you hear about this thing called Bun.

    Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.

    • > Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.

      Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.

      1 reply →

Radical idea here, but maybe those many companies could _fund_ the development of key components of their infrastructure.

  • Indeed, seems like it should be pretty straightforward.

    I understand why the venture-backed entity couldn't do this, but given the reactions here, could a new maintainer not take over and simply charge for support and future enterprise features like the Sidekiq guy?

> So many companies went all-in on Deno in recent years.

They should hire a few devs to develop it then.

Seems like an extremely risky thing to do. Luckily they can keep maintaining it and improving it if their business is truly dependent on it.