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.
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"
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."
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.
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.
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? 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.
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?
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.
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.
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).
You would be surprised how many softwares expect GET with the body. 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 requesta with a body.
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.
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."
Bad news (well not news, this happened a while ago): https://www.cnbc.com/amp/2020/03/16/microsoft-github-agrees-...
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.
> 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.
Bun seems popular too, what would be reasons to choose it?
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.
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
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 requesta with a body.
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.