Top
Best
New

Posted by ilreb 12 hours ago

Cloudflare acquires Deno(deno.com)
1032 points | 534 commentspage 5
sandelz 10 hours ago|
A bit worried what will become of https://github.com/denoland/rusty_v8 as it still is the best maintained (?) and featured binding of V8 for rust.
rough-sea 8 hours ago|
rusty_v8 isn't going anywhere - we'll keep maintaining it and will be working towards integrating it into workerd
sandelz 6 hours ago||
Awesome, thanks for the reply!
makifoxgirl 5 hours ago||
I still remember this cute drawing from years ago outlining the things Ryan regret about Node

https://imgur.com/a/XFAMzOV

hbn 4 hours ago||
Man the "cute girly sketchbook doodle summarizing a programming thing" is a throwback to a bygone era. I saw that and immediately knew "this is from the late 2010s"

I remember early into my first programming job as an intern in 2017 someone shared a very similar looking series of sketches intended to explain git with cats. I didn't understand it at the time, and then years later when I was much more comfortable with git I took a look at it again and the explanations make just as little sense to me now as it did then.

K0IN 5 hours ago||
I was a big fan of deno, so much that I migrated all my cf worker to demo, cause you can run the same engine in there cloud and local/selfhost - perfect no vender lockin(like with cloud flare workers), it's so sad to see it gets shelved.
ofirg 5 hours ago||
If your company does not own an ecmascript runtime ngmi
singularity2015 9 hours ago||
Deno did bring lot of good ideas and hope some of them will flow into Node, especially full typescript type stripping, package less imports to name a few.

Also worth calling out that if you want to disrupt a major player, you need to be 10x better, not just 2x.

Either way, congrats team. Hope you going on to build something great at Cloudflare.

mysterydip 5 hours ago||
I just learned of Deno yesterday when setting up some software for the first time. I wonder how many applications depend on it behind the scenes?
wiseowise 7 hours ago||
So is dead for all intents and purposes. And this would’ve happened to Bun if it hadn’t found its killer app (Claude Code).

Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.

afavour 9 hours ago||
I'll sound smug saying it but this is always, always inevitable from the moment Deno took VC investment. Either it was going to be successful enough to take over everything (and it wasn't going to be) or it would end up acquired/shut down.

I know Node is boring but it's not going anywhere.

galaxyLogic 4 hours ago||
"entire Deno team is joining Cloudflare .."

Whom did they work for before?

gen2brain 11 hours ago|
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
n_e 10 hours ago||
> what should I choose and why?

You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.

Also the other runtimes only offer incremental improvements.

Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.

jerf 11 hours ago|||
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
gen2brain 10 hours ago|||
Yeah, after I posted I realized that Go remark was not correct, but again, I am confused how do you combine all that. JS I can read and understand (well, understand), I have seen it already, TS, I compile TS to JS right, and then I can choose any of the current available runtimes to run that code, correct? And final fat binary that is deployed has what, whatever runtime I choose to be? Huh, I think I guessed that right, I do use such apps, but never bothered to understand how they are actually packed.
mschuster91 10 hours ago|||
> Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code.

It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].

[1] https://github.com/TypeStrong/ts-loader/issues/1671

jerf 10 hours ago|||
Yes, everything I have is pinned that way too. That's why I said "when it is done", even in my limited experience and contact with TS it is not currently a suitable replacement, and I'm not a particularly hard user of the tool chain. (I am having a hard time phrasing this in a way that I'm completely sure can't be potentially read as snarky or short-tempered, so I guess I'll just go with the clumsy direct statement that I'm agreeing with you and continuing the thought from my own experience, not trying to disagree.)

As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.

gen2brain 10 hours ago|||
Well, that "Go crap" needs some explanation. The reason I am not involved in JS is because I mostly use Go for backend, and I am happy I have no relation with frontend at all. And even that is just small part of my job and what I do daily (Radius, Diameter, etc.). But, I never heard about Go crap (in that context maybe), or experienced any crap there, it is just nice and simple. What are the issues?
mschuster91 10 hours ago||
Many of the "rewrite it in Rust/Go/whatever fad" projects that have cropped up have been done with the assistance of AI, especially because both languages are a pretty heavy divergence if you're used to C, C++, Java or JavaScript.

And when you can't manage to coordinate with an ecosystem dependency as large as webpack before the migration to make sure nothing breaks... my suspicion is utter incompetence and gross misuse of AI.

sensanaty 10 hours ago|||
There's basically no reason not to just go with Node as 99% of projects out there do
croes 10 hours ago||
Isn’t the whole node npm ecosystem now with AI a greater risk as before?
thunderfork 9 hours ago||
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
CuriouslyC 10 hours ago|||
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
alexfortin 9 hours ago||
More or less the same but I dropped Bun after Anthropic acquisition so I now default to PNPM and Vitest, which is ok.
seanw444 7 hours ago||
While it may as well be the same thing, the Anthropic acquisition isn't what turned me off of Bun, it was the vibe-coded Rust refactor. As soon as that happened I dropped Bun. Deno was what I ended up more interested in (Deno Fresh seemed really cool too), but I guess it's just back to Node/PNPM for me now as well. What is going on anymore...
CrimsonRain 11 hours ago|||
There's just one worthy of using for fresh project: Bun.

Deno was never going to be a thing anyways.

WorldMaker 8 hours ago|||
Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.
CrimsonRain 3 hours ago||
Bun's rewrite has been a massive success, unprecedented even.

The amount of new features they are coming up with, the speed of development has been even faster than before.

We have not seen any indications so far Anthropic messing with Bun's direction. It was always Jarred deciding what to do and it is still the same. So far Anthropic has left Bun alone and they are just reaping benefits of bun getting faster and faster.

I see that as a long term benefit. Not a negative.

lioeters 9 hours ago||||
Bun is dead. It's a skin-walker wearing the appearance of its former self. They screwed the community when they got acquired.

Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.

CrimsonRain 3 hours ago||
Screwed who actually? How? Dead? lol.

Every company that is using Bun is getting so much more perf benefits — faster and less memory used; also less crashes/bugs. New features are dropping rapidly. All those naysayers about rust port will be littered with bugs and unmaintainable crap are already proven wrong. So now you just call it dead. nice.

SkyeCA 10 hours ago||||
Just use Node. Community led and supported by the Linux Foundation.
righthand 10 hours ago|||
Why not the standard NodeJS? Well supported and not heavily influenced by acquisition or trends like bun is?
CrimsonRain 2 hours ago||
If Deno and Bun were not kicking NodeJS's behind, we'd not see any of the improvements in the ecosystem in last few years. Node has been stagnant for a long time.
mschuster91 10 hours ago|||
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?

NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.

Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.

WorldMaker 8 hours ago||
I'd throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.

Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.

nozzlegear 11 hours ago||
I'd just go with Node, it supports TS natively now.
bel8 10 hours ago||
NodeJS just strips TS types and prays that it runs as JS. It's not a native support by any means.

For example it doesn't support enums.

Bun and Deno do the real thing.

flohofwoe 3 hours ago|||
"deno run" also just strips the types. The type checker is 'opt-in' now.

Don't know what Bun does though.

rslsts 6 hours ago||||
> prays that it runs

If you want to use TS stripping for your own project the typescript ecosystem makes it very easy to avoid using the wrong features. Just set erasableSyntaxOnly and verbatimModuleSyntax to true in your tsconfig.json and you will be warned when you're doing something node would not be able to handle. These days I find more code is being written to be stripping friendly than not, the incompatible stuff is of little importance besides enum for which you could resort to an as const object or a string union. I consider the presence of such things a smell, the TS dev team considers things like enums to have been a mistake, the goal of TS is to remain minimally divergent with JS outside of the type annotations.

nozzlegear 9 hours ago|||
Oh for real? I thought the latest versions ran actual typescript.
brlewis 8 minutes ago|||
>I thought the latest versions ran actual typescript.

That's by design. Deno smoothly hides the fact that TS needs to be converted to JS for V8 to run it. Similar to how it smoothly hides everything about npm.

kevinfiol 5 hours ago|||
Well, it does technically in that to "run TypeScript" all you have to do is strip the types, and execute the remaining JavaScript. This is what Node does, but it doesn't do any typechecking. You can always include TypeScript as a dependency to do the actual type checking for you.

Deno from my understanding included a version of the TypeScript compiler as part of its build. Node doesn't do this. I'm not sure what Bun does, but I wouldn't trust it for anything more than a hobby project.

More comments...