[tarruda]

I think the main appeal of projects like Bun and Deno is the built-in tooling for building/bundling modern typescript applications without requiring dozens of dependencies for even a basic hello world app.

If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly.

[pjmlp]

Being an old dog in the prairie, I see the outcome of these projects being like egcs, and io.js.

They create some riff, make the key incumbent improve itself, and then the world moves on as if nothing happened.

[vorticalbox]

> If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly.

I believe this too. The big appeal for me is not having to install typescript, eslint, jest AND then set up all the configs.

deno has nice defaults, though the importing via URLS and browser compatible API do make deno very tempting

[willsmith72]

that feels like a really weak value prop to me. how often do you have to install that stuff? how hard is it actually? can you really not use, e.g. for react, the typical vite starter and it's done?

[mcintyre1994]

The other side of it is if you want to distribute your code not as a server. If you write a CLI in Node + TS + ... then it might be pretty fiddly for someone to clone that repo and get it running locally. You'll certainly have to document exactly what's needed.

Whereas with Deno you can compile to a single binary and let them install that if they trust you. Or they can `deno install https://raw.githubusercontent.com/.../cli.ts`, or clone the repo and just run `deno task install` or `deno task run`. For those they need to install Deno, but nothing else.

[mcpeepants]

> then it might be pretty fiddly for someone to clone that repo and get it running locally

with node + TS, it is straightforward (and common) to generate JS output at publish time for distribution. then, using the CLI tool or whatever is only a `npm install -g <pkg>` away, no extra steps.

sure it's not a single binary, but I'd argue _most_ users of a general CLI utility don't necessarily care about this.

[Kinrany]

For one-off scripts: every time.

So Deno is better at small scripts written in Typescript than Node. Then, the question becomes, if you're going to have Deno installed and if it works well enough to replace Node, why keep Node?

[willsmith72]

then you have to define "works well enough to replace Node"

i was excited about bun too, until v1's "drop-in node replacement"

that was in no way a drop-in node replacement. using that would be the fastest way to kill a business with its terrible bugs and rough edges.

i used to be really excited about deno, but now i think the tradeoffs aren't going to be worth it for mass adoption. i sometimes write servers in go. now that i have go installed, should i use it for all my servers? no, it's just another tool with different trade-offs. most times, node will suit my project better.

[tarruda]

It is more a matter of trust than effort, eg being less exposed to supply chain attacks.

[spartanatreyu]

> how often do you have to install that stuff?

> how hard is it actually?

> can you really not use, e.g. for react, the typical vite starter and it's done?

I have to install that stuff everytime I'm starting a new project, switching to a new project, or creating a one-off script.

It's hard when creating a new project where there's always at least one flag that needs to be found and set different from a previous project for some random reason, every single time.

It's hard when switching to a new project, because you have to figure out which version of node you're supposed to be running because each version runs the dependencies differently between different versions of node, and different computers. It might even silently work for you without being on the right version, meaning you continue working on it, then your commits don't work for yourself later or others now or later. This leads to one of two possibilities:

1. A longer job either unwinding everything to figure out what the versions should have been the whole time.

2. A lot of trial and error with version numbers in the package and lock files trying to figure out which set of dependencies work for you, work for others, and don't break the current project.

We also can't use the typical community templates because they always become unmaintained after 2 years or so.

---------------------------

Why I like Deno:

- Stupid easy installation (single binary) with included updater

- Secure by default

- TS out of the box (including in repl making one-off-scripts super easy to get started)

- Settings are already correct by default.

-- and if you ever need to touch settings for massive projects, they all sit in one file, so no more: tsconfig/package.json/package-lock/yarnlock/prettier/babel/eslintrc/webpack/etc... And since the settings are already sensible by default, you only need to provide overrides, not the entire files, so the end result for a complex project is usually small (example link: https://docs.deno.com/runtime/manual/getting_started/configu...)

- Comes with builtin STD meaning I don't need to mess-around with dependencies

- Builtin utilities are actually good so I don't need to mess-around with the rest of the ecosystem. No jest/vitest, no webpack/rollup, no eslint/prettier/biome (but you can keep using your editor versions just fine).

- Since it came after the require -> import transition, basically everything you're going to be doing is already using the more sensible es modules.

[vorticalbox]

its not that much of an issue, i have created a template repo in github that i can make new projects but not I have to maintain it.

[pjmlp]

Except they are playing catch up with what Microsoft says Typescript is supposed to mean.

I rather have pure JavaScript, or use the Typescript from source, without having to figure out if a type analysis bug is from me, or the tool that is catching up to Typescript vlatest.

[whstl]

> without having to figure out if a type analysis bug is from me, or the tool

Deno uses regular Typescript for static type checking, it's just built-in. Bun also doesn't do type checking by itself, they recommend using tsc [2].

[1] https://docs.deno.com/runtime/manual/advanced/typescript/faq...

[2] https://bun.sh/docs/runtime/typescript#running-ts-files

[pjmlp]

Until they bundle Microsoft's compiler, it isn't the same thing.

It is like tracking down if a C bug in GCC relates to developer, or GCC understanding of ISO C documentation.

Just this alone proves it isn't the same thing,

=> Deno tries to keep up to date with general releases of TypeScript, providing them in the next patch or minor release of Deno.

[whstl]

The “Microsoft compiler” is exactly what tsc is, and is exactly what is bundled with Deno. Sorry if that wasn't clear.

[incrudible]

Not sure what modern typescript means, but you only need one or two dependendencies (esbuild and tsc) unless you are doing something more involved, in which case deno alone might not work either.