[h1fra]

I still don't understand the true goal of Deno.

It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it's not flexible enough but painful enough that you want to allow everything straight away. The module system suffers the same issues as of npm, and since everything is loaded from the same domain its hard to tell what is official or not.

They have a builtin server, linter, testing, benchmarking, a hosting platform, now a kv store.

I feel like they are getting away from being a language and heading toward being a framework. Why not, but will probably not help adoption imo.

[brundolf]

> The module system suffers the same issues as of npm

Tough to interpret this since NPM isn't a module system, but:

- Requiring the standards-compliant ES module system and getting rid of CommonJS is definitely a huge improvement for the future of the ecosystem

- If by "the same issues as npm" you mean "makes adding dependencies so easy that a lot of them get added", then sure I guess, though I'd argue that isn't an issue

> since everything is loaded from the same domain

It's not though; Deno can import from any URL. Personally I like to import directly from github for a lot of things. But anyone can set up their own repository or CDN if they'd like to, because all you need is an HTTP URL

> its hard to tell what is official or not

The official standard library is under deno.land/std/

> I feel like they are getting away from being a language and heading toward being a framework

Well they were never a language because the language part is (almost) identical to what was already out there. Whether or not they're a "framework" (or attempting to be one) is debatable, though they definitely take an "all the things most people need have official solutions (which work together smoothly)" approach, which is one of my favorite things about Deno. Also, a major usecase (their core business) is serverless scripts, so having all the important stuff included is even more beneficial there

I've stopped using Node for any non-UI projects. Deno has been a godsend for me

[veidr]

Wild take, but agree with your first sentence.

1.) it was never a language

2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.

[LunaSea]

I see close to no case where you would not enable all access rights

[veidr]

Well they might not be your use cases, but surely you can imagine them, right?

A build tool, that reads input files and writes output files, and nothing else.

A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

A serverless function that doesn't need anything but networking.

Even when you need to allow whatever you're building to read the filesystem, just specifying which files/folders can be read is in an of itself a huge win.

Thinking on it a little more, I wonder what kind of gigantic monolith use cases are there that need to read/write completely arbitrary filesystem locations, and need to spawn subprocesses that can't be known ahead of time, and need to do networking, and need to read arbitrary environment variables that can't be specified ahead of time, and also need to load dynamic libraries, and also need that other permission I'm forgetting?

I mean, I am sure there are some, but that certainly isn't the default I'd choose.

[LunaSea]

> A build tool, that reads input files and writes output files, and nothing else.

If it wants to upload artefacts to a CDN it will also require network access.

> A CLI that interacts with the bug tracker, and needs to read the environment variables and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

Chances are the CLI needs to read ENV variables to authenticate or a configuration file and maybe even subprocesses to setup parallel processing.

> A serverless function that doesn't need anything but networking.

A serverless function will probably read environment variables as well or access a package.json file to read some context about the name of the package and it's version.

My point is that most programs will require all access enabled.

[veidr]

I know that's your point, but I don't understand why you think that.

Even with your own theoretical additions to what the programs above need, none of the programs above actually need "all" access enabled.

And even when you do need to allow environment variables, subprocesses, and filesystem access, you can specify which ones. E.g. this program can read this specific package.json file and no other files. Or these three specific environment variables, and no others.

Which is still significantly different than "all".

[hv42]

I found it really to be the perfect shell script replacement. People usually will use python for more complicated shell scripts but deno is just awesome at this. Just run the file and eventually cache the dependencies for the next run. No node modules or pip install etc Also, you can use typescript without any pre-bundling.

The security model works well for this use case also. If your shell script is only supposed to read a few environment variables and not make network calls, you are covered.

[tough]

Deno is really useful on edge computing like serverless lambda functions in things like NextJS/Vercel or Supabase and such

[paulryanrogers]

Why? Performance? Security?