> Secure by default. No file, network, or environment access, unless explicitly enabled.

Great, but we're talking about server software so the first thing any project is going to do is enable all of that. And it's not like you can trust this on the server, you'd still need to sandbox to process if you truly want isolation.

> Supports TypeScript out of the box.

Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps?

> Ships only a single executable file.

I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem.

> Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).

Is this not the job of the package manager? Or does deno force you to use itself as the package manager? Will that not just bring about another npm situation in a few years?

I feel like I'm clearly missing something with how excited everyone is about deno, but I have no idea what it is.

[1] https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussio...

[1]: https://deno.land/manual@v1.13.1/linking_to_external_code/im...

That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.

[1] https://nicedoc.io/crewdevio/Trex

Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded.

There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.

Trex doesn't do anything about transitive dependencies and package deduplication, what my critique is about.

This is kind of like saying "Oh it supports Javascript? So now I'm tied to Netscape's take on browser scripting?" at this point. Typescript has won the JS compiler wars and become the defacto standard for the community.

edit to add: I'm serious. JavaScript tries very hard to not have backward breaking changes. TypeScript does have breaking changes at about ever minor release. The TypeScript team manages the project as a versioned tool, not as a distributed environment like the web. afaik, Deno hasn't really solved this problem, so there's a chance your code breaks when Deno upgrades its TypeScript version.

Even so, they could limit such breakage to major Deno versions with other breaking changes, if necessary. Not sure if they do.

2 - personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem. That of course may change in the future of course, but today it feels like TS is where its at.

3 - I've experienced a lot of annoyance shipping around huge node_modules/ directories, just to get a CLI app working. Sure these are not "problems", but it is a pain to have to compress up hundreds of thousands of files and then decompress again rather than just moving around one executable.

4 - deno is the "package manager", if you can call it that. You explicitly state the imports & versions you need in your code as import statements, and the deno runtiem handles sourcing the files for you transparently. So either from a cache, or at first run it will try and go out onto the network (internet or proxied IIRC) to get them for you.

There are a bunch of nice languages featuring good FP support that compile to JS that are have viable sized developer communities and longer histories than TS. For example ReasonML, ClojureScript, Flow and Elm. Then you have the bunch of languages that compile to asm.js or WebAssembly. Not to mention the majority of Node and FE developers who continue to use JS.

TypeScript integrates with the JS ecosystem, often major JS libraries include typescript definitions in the box, or are even written in typescript.

Flow has been obsolete for a while now (yes I said it).

I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS.

[1] https://www.typescriptlang.org/docs/handbook/2/generics.html

The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.

Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation.

(More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833)

Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".

I don't think this is true any more. According to https://2020.stateofjs.com/en-US/technologies/javascript-fla... 78% of JS devs actively use TypeScript

Meanwhile, the StackOverflow 2020 survey, which reached twice as many JS developers (54k vs 23k), saw that only half of JS developers reported using TypeScript. (not counting any developers that reported using TS but not JS, which would drive the percentage further down). Again though—people who are more likely to fill out random surveys are going to be more plugged in to new technologies and more likely to adopt them.

I've never used Typescript, and I don't plan to. I don't care about static typing. It's nice occasionally, but I don't find that the structural problems I need to solve day to day when working on large codebases are the sorts best solved by static typing. When working on hobby projects, I don't use JS compilers at all, the set of JS supported by modern browsers is already very expressive and iterating very quickly.

Personally I find hard and scary to change things in js and being confident that it would work without breaking anything, with typescript I have that, some function rename, change parameter type, add/remove/rename object fields etc.

I found a couple of times when migrating some files to typescript misspelled names that would be hard to catch and passed the code reviews, that’s and easy task for the computer but harder for the developers, also using tools that makes your code reviews easy its great.

Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful.

> Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

You've certainly convinced me that Deno's single binary deployment is a useful feature.

As a frontend dev, I use node tooling every day that has nothing to do with server code.

> Python is much better as 'general purpose'

Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem.

That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever.

Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable.

But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.

3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies.

I haven't used CodeArtifact, but is it something you can deploy on-premise?

You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks.

Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.

I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS.

[1] https://news.ycombinator.com/item?id=15090561

JavaScript is strongly typed in the sense that every value has a well-defined type. It's weak in the sense that it has implicit conversion between types in a lot of cases, but it's not as though those conversions don't follow particular rules if you know the types.

TypeScript gives you accurate static typing on top of that, so long as you don't use `any` as an escape. Arguably, `JSON.parse` returning `any` is the 1-million dollar mistake of TypeScript, because it leads a lot of people to think that they get automatic runtime typechecking for free, which they obviously don't, which leads to comments about how bad/slippery TypeScript is stemming from their misunderstanding.

In my experience, you only need to work around typings in TypeScript when you're dealing with some absurdly designed API that only made sense in the super-flexible world of olden-days JavaScript, or perhaps if you're doing some meta-programming, generating class definitions on the fly or such.

That may sincerely be, because how it feels as you're using it doesn't align with the objective truths of how it behaves. The definition of a strongly typed language has been well-cemented for some time. TypeScript does not completely align with that definition, thus it cannot be considered truly strongly typed.

Wikipedia disagrees with you in the opening paragraph about strong and weak typing: it's contentious. For all practical purposes that I can think of, TypeScript creates a strongly typed environment.

The problem comes when you're interacting with non-typed (or, worse, incorrectly-manually-typed) libraries, or misuse `any`. Honestly, I'd be interested to see a pure TypeScript program and where weak typing comes in. There are definitely a couple of language escapes (again, `JSON.parse`, previously `fn.bind`), but these are going away as TS gains better inference and type-propagation logic.

What is it? Is e.g. C++ strongly typed in that sense?

But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.

Everything gets compiled down to the same machine code in the end.

Yes. It seems the majority of engineering decisions are tighly coupled to this expression right there. Future be damned because a Medium.com ex-FAANG said TS is where it's at

Bless them and the hype train, woe to developers 5 years from now.

Ditto. It's also important to remember that TS transpiles to JS, so you're not locked in in that sense.

(I've actually seens TS-to-JS-transpiled code that is much better than code that was written in/as JS in the first place.)

Just let the computer handle this trivia and concentrate your efforts on adding value I say. Sure it takes an hour or two to set up the tooling, but once you are up and running there is no overhead (unless you consider defining types an overhead). Compiles take a fraction of a second and the browser has usually already reloaded itself before you've even physically moved your eyes over to the other monitor

Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.

  basically you just described dynamic languages here. We know why and how to program in a dynamic language. We don’t want that though. People that are using TypeScript are using it for the static typing.

Using typescript is very progressive, you can add types line by line if you want. There's not much setup really other than using TSC to compile the files.

There’s not a reason you’d migrate an existing node project to deno, but if you’re starting something new, why not use the nicer environment?

FWIW, deno is also built by Ryan Dahl, the original creator of node, so I think of deno as more like a rewrite of node rather than a competitor.

> Great, but we're talking about server software so the first thing any project is going > to do is enable all of that. And it's not like you can trust this on the server, you'd > still need to sandbox to process if you truly want isolation.

These are not intended to be quick fixes for the masses nor replace sandboxes. They contribute to strength in depth and frustrate attackers looking to make pivots. I'd recommend taking some time to consider the threat models that these measures are align to.

There is evidence that making changes like this contributes to the overall security of an ecosystem. You have a smaller percentage of people who will go ahead and do the wrong thing initially (if you support them with proper guidance), but it's only over time that you have projects based on the platform. More importantly, a change is being made that can sustain a culture of security over the long-term.

When you have to maintain systems that aren't built on platforms with support for measures like these it becomes difficult to retrofit any meaningful level of security, or there is too much obfuscation in the system to justify improving it without rewriting it. Here you can see that the original implementers have enabled privileges unnecessarily and there is a clear angle of attack. Along the way you can also revert all other kinds of bad practices and hacks that previous developers implemented (random calls to external services you don't expect, loading configs from disk that should be loaded another way, etc.) These are not uncommon experiences when technology gets into the hands of the mainstream.

My reasons:

- Types: I simply cannot program without them. Typescript is great.

- Single executable: Write programs that run the same on Linux/Windows without forcing the user to download the entire universe like other runtime environments.

- Built-in bundler: Write front-end code in Typescript and use a single command to bundle all dependencies.

Native JSON support in cli applications is not something you can appreciate if you haven't dealt with the pain surrounding it on the Java side.

There are so many better options if you want a good type system (Elm, PureScript, Rescript, GHCjs, Scala.js, and many more). TypeScript is unsound, and necessarily by it's design, it has to take on weird issues to maintain compatibility with JavaScript (null/undefined, can run effect anywhere, a lot of codebases are filled with any types). Heck, TypeScript doesn't even come with ADTs and proper pattern matching.

I am looking for basic type checking to prevent me from doing stupid things and catching bugs at "compiletime" instead of runtime.

Typescript interfaces with their structural typing do the job just fine.

I think people are underestimating the power of ecosystem. I use JS daily. Deno allows me to use it on the server as well without doing crazy things.

You have been able to do something similar in Java for a very long time with Mozilla Rhino (and now GraalJs) but without the same level of comfort and convenience.

You still can use them [0].

> proper pattern matching

[1] is pretty good.

[0] https://itnext.io/practical-introduction-to-algebraic-dataty...

[1] https://github.com/gvergnaud/ts-pattern

> A TypeScript-like language for WebAssembly.

> AssemblyScript targets WebAssembly's feature set specifically, giving developers low-level control over their code.

> Being a variant of TypeScript makes it easy to compile to WebAssembly without learning a new language.

> Integrates with the existing Web ecosystem - no heavy toolchains to set up. Simply npm install it!

And in any case I don't think anyone is really saying "Use Deno because it has static type annotations". It's "Use Deno because it has static type annotations and is fast and easy to deploy and has a huge ecosystem and doesn't require a project setup file to use third party libraries and ..."

> - Single executable: Write programs that run the same on Linux/Windows without forcing the user to download the entire universe like other runtime environments.

OK, I understand your comment wrt Java, but with shellscripts? What universe are you downloading?

For that matter - your 3 listed reasons make a very argument for "a normal compiled language". Consider an older/popular one...C++. It's very typed, compiled to a single executable, and "bundling" is "linking"(you can do it any way you like, including staticly linking all your deps).

If I understand your comment, are you saying that previously you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)?

I'm not denigrating JS/deno/node/whatever, I'm pointing out your 3 reasons are built in features to any compiled language in the last 40 years.

Not just Java. Python, Ruby, Node etc suffer from the same problem. And I am talking as an end-user here.

I once downloaded something based on one runtime which then proceeded to download another runtime which it needed to run one little script. There are programs out there that have node/npm as a dependency.[1] People are crazy.

> your 3 listed reasons make a very argument for "a normal compiled language"

One of my hobbies involves writing compilers and parsers.[2][3] I have tried a lot of "normal" languages and have stuck to Java (in spite of its excessive verbosity) for work reasons. Some languages I cannot tolerate for aesthetic reasons.

For now, there is no alternative to TypeScript.

> you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)

I used to run a mixed-environment (Windows + Linux) and a lot of glue code that drove other software had to be written twice (sh/bash + cmd/bat) before WSL came along. That problem has disappeared.

I also used to write a lot of tools (servers and cli apps) in Java. Some of those I have moved over TypeScript-on-Deno.

> I'm not denigrating JS/deno/node/whatever

I used to look down on JS a decade or so back. My experience with Rhino and now Deno changed that. There is a lot of stuff I do now which I simply would not do if I have to fire up an entire Java project to do.

[1] https://archlinux.org/packages/community/x86_64/nodejs/

[2] https://github.com/s-i-e-v-e/ut

[3] https://github.com/s-i-e-v-e/sxml

Are shell scripts cross-compatible if you haven't installed WSL?

So how is this statement wrong for shell scripts? You can't write a shell script that "runs the same on Linux/Windows without forcing the user to download a runtime" because you can't write a shell script that runs on Linux/Windows.

> Why use js,

For someone working with JS on the front end, the ability to not only use the same language, but also the same libraries/modules/functions is very valuable.

> which is slow?

Not that slow, once a JS engine takes over.

The thing that attracted me to Deno is that it promises to be a more integrated Typescript experience on the backend while still leveraging a lot of value from the Node ecosystem. I've already forced my coworkers to use Typescript, so having better integrated tooling is just a big plus.

That's when compared to Node.JS. When compared to other frameworks, I'll just say it's nice that all developers on my teams know Typescript, so they can all contribute when necessary. In absolute terms, I think Node.JS is the dumbest thing to ever happen in IT history, and I hope something like that never happens again. That Deno puts a small bandaid over that open wound in my heart is nice.

Did you already forget about PHP? :p

- Why using CommonJS over standard ESM modules?

- Why using a package manager like NPM? Browsers don't have package managers, my code can run on the client without something like NPM, why should it be any different on the server?

- Why having callback-based APIs in a world of promises and async/await?

- Why having node-only APIs when today standardized browser equivalents exists?

- For better or for worse as far as I'm concerned TypeScript is the de-facto successor of JavaScript, especially if you need to work on big codebases. Flow is irrelevant outside of Facebook. If something better pops up Deno could adopt that too or you could just compile that to JS yourself and Deno would work with it already. As things stand currently other compile-to-JS languages are way less important than TS.

- Servers aren't the only kind of application that can be written on top of Deno, why on earth would I want eslint to be able to have access to the network or spawn child processes? Or even have global read/write access to my whole disk? Deno's model is a much better default than Node's from a security perspective. You can't even install something from NPM with reasonable certainty that that won't nuke your computer.

Essentially switching from Node to Deno may not seem like an obvious improvement, but it is in many ways, switching from Deno to Node has only drawbacks basically, if you don't consider Node's advantage in ecosystem size I can't imagine why anybody would switch from Deno to Node in the future.

I'm sure many (most) will but the point is that for those who do care about security, Deno offers them the option of running their server app with such features selectively enabled according to need.

> it's coupled to Microsoft's take on Javascript

Deno supports Javascript too so there's no tight coupling here. It's also a second well-supported widely-used independent implementation of microsoft's syntax, which is no hard guarantee of anything but bodes well if vendor lock-in is a concern.

> What about Flow

Flow is significantly less popular so this decision seems understandable. I cannot see Deno being as popular as it is now if they had opted for Flow.

Also, while Flow has some advantages, it's a lot less expressive and most reviews of both prefer TS for quite well-argued objective reasons.

> What's wrong with using Babel with sourcemaps?

Given the complaint about coupling just two sentences previous to this one, this makes your comment seem quite disingenuous. Are you serious???

> Will that not just bring about another npm situation in a few years?

It might but your goalposts seem to be moving. Are you saying this makes it worse than npm somehow?

Except that we aren't talking about server software. Node is a js runtime environment, and it is being used for other things like scripts and CLIs.

> I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem.

There are a ton of CLIs made with node that need to be installed globally. As someone that never uses node this feature would help me keep my binaries explicitly and tidily under `~/.local/bin`.

The command to do that is called `compile` but its a bit of misnomer, it does not compile a free standing executable with your code but basically creates an executable wrapper around `./deno yourcode.ts`.

What I wonder is how big hello world is for a statically linked packaged dene application, and if it's easy to produce those (assuming 50MB is for linked binary). That's probably more useful in a lot of cases if it's not wildly larger.

    /tmp$ mkdir test
    /tmp$ cd test
    /tmp/test$ curl -sOL https://github.com/denoland/deno/releases/download/v1.13.1/deno-x86_64-unknown-linux-gnu.zip
    /tmp/test$ unzip deno-x86_64-unknown-linux-gnu.zip
    Archive:  deno-x86_64-unknown-linux-gnu.zip
      inflating: deno
    /tmp/test$ cat > test.ts
    console.log('Hello, World!');
    /tmp/test$ ./deno compile test.ts
    Check file:///tmp/test/test.ts
    Bundle file:///tmp/test/test.ts
    Compile file:///tmp/test/test.ts
    Emit test
    /tmp/test$ ls -lh
    total 198M
    -rwxr-xr-x 1 user user 83M août  16 23:52 deno
    -rw-rw-r-- 1 user user 32M août  23 19:12 deno-x86_64-unknown-linux-gnu.zip
    -rwxrwxrwx 1 user user 83M août  23 19:13 test
    -rw-rw-r-- 1 user user  30 août  23 19:13 test.ts
    /tmp/test$ ./test
    Hello, World!

    $ ldd deno
        linux-vdso.so.1 (0x00007fff3fbeb000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007efd30939000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007efd30721000)
        librt.so.1 => /lib64/librt.so.1 (0x00007efd30519000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007efd302f9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007efd2ff77000)
        libc.so.6 => /lib64/libc.so.6 (0x00007efd2fbb2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efd34593000)

Beyond that, you still have the v8 engine running the JS, so yeah in most cases performance will be pretty much what you can expect from Node _except_ with regards to anything that reaches out of the sandbox (like filesystem or network access). These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages, and Promise-based APIs all the way down. For the builtin HTTP server for example you can expect higher throughput from Deno. Tail latencies also tend to be better with Deno.

You're not immediately going to get "blazing fast, native speeds" but you can get some nice optimizations.

Very cool, thanks for the detailed answer.

Speaking of which, I was wondering if it has an equivalent for "npm audit", and I've found a project which provides some of that capability:

https://deno.land/x/audit@1.0.0

Rather than rely on a single source of truth for audits, it seems to rely on developers specifying a location which is trusted to make audit reports about their modules.

That's a slightly different trust model, but it's better than nothing and at least prevents the controversial false positives problem of "npm audit":

https://news.ycombinator.com/item?id=27761334

- As I’ve adopted ESM, I’ve found Node’s ESM support difficult to deal with. Deno being ESM by default is a huge improvement, and makes portability to other environments much easier.

- Similarly, Deno’s default deferral to existing JS/browser standards helps portability immensely.

- TypeScript isn’t just supported, it’s very fast! Much faster than solutions like ts-node. Not limited/incomplete like current esbuild-based ESM loaders (though I’m actively working on solving that for Node).

- Async APIs are all Promise-based. No legacy sync/callback/promisify.

- Import maps allow complete flexibility with dependencies: you can use NPM or another package manager if you really want. You can customize package management however you prefer. You can completely sidestep NPM audit hell.

- The standard library is good actually! And it’s ESM so it’s immutable by default.

- Quite a lot of stuff that requires build tooling (eg isomorphic web) is not needed server-side at all. But I was curious about your questions about Babel/Flow and it looks like there are APIs that allow you to customize compilation if you need to.

Basically... we’re a “TypeScript native” project from day zero... so why do we need to be weighed down with all this cruft from historical JS ecosystem decisions? I’m planning to try swapping one of these services to Deno to see how much easier it is.

I don’t mean to denigrate; Node and Deno (already) are far bigger success stories than I’ll ever have.

- Security; - More suitable for Serverless deployment (like running a full server on V8 Isolates) - Cloud Workers and Fastly (0ms cold starts)... check this out -> https://deno.com/blog/deploy-beta1 - Embraces Typescript as a first class citizen.

Especially in combination with content addressed file systems like IPFS (which gives you additional features like built-in checksums, immutability, de-duplication and storage resilience) you can have a Deno instance running and as the deployment step simply send it a file hash or URL to execute (of course with the appropriate security precautions like a signature or encryption on top). I built a prototype to see how it could work and a full Deno app deployment to my own VPS took less than 2 seconds. No git pushes, no container build pipelines, no proprietary cloud services.

The big one for me is, ability to use async/await instead of supplying callback methods.

- Follows the ecmascript standard and supports browser apis

- No npm, no Microsoft lock-in

- So far, no political bs like node has had

You still need packages

> no Microsoft lock-in

Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs.

Which you import just like you would in a browser.

> Does Deno implement its own TypeScript compiler?

Deno is a JS engine that aims for maximum compatibility with browsers.

While not exactly a second class citizen, losing Typescript (if it comes to that) is something the platform can survive. Ryan is on record saying that adding Typescript support at a very early stage was probably a mistake.[1]

[1] https://www.youtube.com/watch?v=vBd4tPUBUQo

Import them from where?

Also, if I have more than 10 packages, it makes sense to bundle them

> While not exactly a second class citizen, losing Typescript (if it comes to that) is something the platform can survive.

That is not what I asked/pointed out

A url. The files are cached. You can always explicitly vendor dependencies and use relative imports (or import maps) if you don't want to rely on random urls.

> Also, if I have more than 10 packages, it makes sense to bundle them

And Deno has a built-in bundler.

Which url? How do I find this URL? What happens when that package specified dependencies?

> You can always explicitly vendor dependencies

How? Manually? By scraping urls?

"Just import them". From where?

> What I am much more worried about is all the packages hosted on npm. At any time Microsoft could do something

So, how does deno help?

> So, how does deno help?

By decentralizing the package hosting.

https://news.ycombinator.com/item?id=28284930

> By decentralizing the package hosting.

These are empty words that literally mean nothing. The rest is at the link so as not to have the same conversation in several places.

Litterally anywhere. On Github, on the Deno webpage, in a slack chat message. It is how the browsers has worked for ages and there's never been any issues with that. If the package has deps Deno will download them too in the same manner.

It also means that if there is any problems or dissatisfaction in how your dependencies are hosted you are free to change it to another hosting solution.

> These are empty words that literally mean nothing. The rest is at the link so as not to have the same conversation in several places.

What do you mean it doesn't mean anything? It means that there is not one single place where you have to get your dependencies from. You may think of it as something negative, but I think it's great.

So, Instead of convenience I now have to hunt for some urls somewhere.

> It is how the browsers has worked for ages

1. Deno is not a browser

2. For ages any website would try and host those libs themselves (or bundle them... and host themselves).

From development point of view having to hunt down urls "in slack messages" is a nightmare.

> If the package has deps Deno will download them too in the same manner.

In which manner? How does Deno know that a dependency X lives at url Y that was posted in a Slack channel somewhere?

> It also means that if there is any problems or dissatisfaction in how your dependencies are hosted you are free to change

How am I free to change it if a package I depend on specifies it dependency at a url x, and that package's dependencies specify them at url Y?

> What do you mean it doesn't mean anything? It means that there is not one single place where you have to get your dependencies from.

Right now with npm I'm not getting my dependencies from a single place called npmjs.org. I'm getting from a company-provided package repository. How does that work with "any random url you got from Slack"?

BTW. Developers arguing that package management is bad is a new thing to me.

It's not true in a very, very, very big and important detail: once I found the packages, I do any of `npm/yarn/pnpm install package-name`, and it resolves the package, and all its dependencies

> Since each dependency is an url, it will fetch all deps and download them in order

How is each dependency a url when it's decidedly not? Or is deno silently re-writes all `package.json`s?

> You also don't need a package.json

Oh. Now you don't need a package json. So... How does Deno resolve dependencies for a package?

> I personally prefer to not be reliant on an american mega corporation which is known for it's anti-competitive practices and woke agenda.

Instead you rely on something that literally relies on megacorps for Rust, V8, Typescript.

> Well in that specific case you would need to download the entire tree and host it yourself.

Wow. So much convenience. I'm simply astounded. How is this a good thing again?

> I am convinced it's the future for server side javascript. It's just... nicer in general.

So far you've done literally nothing to show how it's nicer. For a developer it's a major pain in the butt: resolve dependencies manually, download them manually, grep+replace urls...

Edit: this comment by spankalee sums it up nicely: https://news.ycombinator.com/item?id=28276908

What limitations have you run into?

Yes.

> What limitations have you run into?

Libraries that exist for node that can't easily be ported over that don't yet exist for Deno. But that is basically it. In the beginning it was a bit hard to keep up with the rapid changes as well but that seems like a positve thing anyway.

Because it can accept any URL as a dep in the source files, you can in theory do some cuter, weirder things with it. But security wise I’d argue arbitrary URLs, for critical, high traffic deps, are harder to fix when bad things happen, without centralized control.

How do I pin the versions of my dependencies? i.e. where is the package lock file?

If the idea is that every source file will specify the version it wants of every dependency, that seems unmanageable. Or if every source file just imports the latest version of its deps, how do I get reproducible builds?

I want a lockfile with an explicit manual step to update dependencies. “npm ci” seems to work well. I don’t see how Deno improves on it, quite the reverse.

Edit to add: hmm, there are some docs here that look relevant: https://deno.land/manual/linking_to_external_code/integrity_... But this reads as “if you really want package integrity, here are some awkward commands you can run to do it”. I strongly feel this should be the default behaviour that the tools should steer you towards. And in the examples on this page, the source code does link to specific library versions; I have a hard time accepting that that’s a good idea, except possibly for major versions.

The package integrity and import maps sections of the docs look like they do everything that’s needed, they just look fiddly to use correctly.

Maybe it just wants something as simple as an optional .denorc at the root of your project to set the default flags?

It's also pretty easy to vendor in your dependencies so that they don't move between the time you commit and the time your server starts. We also support lock files so you don't _have_ to vendor your deps too. Versioning is up to the server you import from, but typically you'd put version in the URL somewhere (ideally a pinned version).

Security-wise, There are other articles out there that detail this but it's not fundamentally less secure than importing from npm as you're still pulling a JavaScript file from the internet in both cases. The cool thing here with URLs is that it's pretty easy to audit and create an allowlist of known-good and trusted servers to import from in your org.

As for vulnerability reporting & patching; I think we're still lacking a good vulnerability database, that much is true, but fixing deeply integrated deps that have vulnerabilities is pretty easy using import maps really.

It's not the first time I see this claim in this discussion. Describe "easy".

In the case of the much-hated npm, or yarn, it's as easy as:

   npm/yarn install package

Additionally, it's quite trivial to make npm/yarn to pull not from npm, but from, say, a private package registry that only has vetted and audited packages.

So. Given that "it's easy to vendor in your dependencies", how will all this look in Deno?

We already know that even such a simple thing as lockfiles is, multiple manual steps with awkward parameters to the cli that people shouldn't forget [1]. This is... not easy.

[1] https://deno.land/manual/linking_to_external_code/integrity_...

I agree there is nothing fundamentally less secure in general, but what you don’t get is being able to standardize around security for dev account protection, policies around immutability, DNS stuff, and some other centralized security measures. Neither are bullet proof, but there are some things you can’t protect against with random URLs.

I’d argue URLs are fine until you get massive use of a single package and it weaves itself into a complex dependency tree across multiple other critical projects. Then you worry about the what if’s.

This is already an issue with npm. My personal take on this is that at that point that dependency should be vendored as much as possible but obviously it's hard to fight the existing inertia on this one. Also worth noting that the [std lib][1] is an attempt at a pragmatic solution to the problem where these foundational packages that are seemingly used by every framework out there essentially converges to the standard lib. I agree it's not perfect at the moment but it's a start.

[1]: https://deno.land/std

Point being it most definitely was hot garbage, but I feel like most of the biggest pain points have been fixed. Not all of them, and the history of being hot garbage certainly rears its head every now and then, but for the most part npm just works for me these days and I don't have complaints.

I think your bias is showing.

> Great, but we're talking about server software so the first thing any project is going to do is enable all of that. And it's not like you can trust this on the server, you'd still need to sandbox to process if you truly want isolation.

See below re: static builds, but they're making decisions that render Deno much more useful for cross-platform desktop distribution ("what do you mean, cross platform scripts are already easy to distribute" LOL I mean cross-platform including Windows) than Node, or most other scripting languages, for that matter.

> > Supports TypeScript out of the box.

> Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps?

Having it built in means your JS build Jenga tower can be a little shorter, which is great, because the JS build ecosystem is batshit crazy. TypeScript's the right horse to back because it's become a de facto standard already—its tooling is much better than Flow, for one thing, and a lot of people seem to prefer its style. It's a better choice than other compile-to-JS languages because it's very close to vanilla Javascript, to the point that you can tell it to compile to JS that looks hand-written and clearly maps to what you wrote in the TS (this is because its compilation process is mostly just stripping out all the TS stuff). To adopt something like Elm would be to ask developers to develop a completely different language, not just JS-with-static-types. Why static types built-in at all? It can allow for good advances in tooling and performance that wouldn't be available without it.

> > Ships only a single executable file.

> I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem.

This is, to be blunt, fucking wonderful if you're distributing to both Unixy operating systems and Windows, especially if you don't have tight administrative control over all machines involved. Vendoring in stuff like your script runtime is brilliant for preventing all kinds of problems, and if it's a single static binary or (even better) produces static bins that bundle your script, too, then that's very easy to do. Besides, dealing with NPM (or any other language package manager—pip, etc, they're all a pain in the ass when it comes to distribution) on the user end sucks, so you're going to want to bundle everything up in one file anyway, one way or another, if you can.

> > Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).

> Is this not the job of the package manager? Or does deno force you to use itself as the package manager? Will that not just bring about another npm situation in a few years?

This is one thing Go got very right. Building in the basic tools is the right thing to do.

> To be confident in or convinced about something's viability, veracity, etc., often to the point of being enthusiastically supportive of it.

People on HN seem excited about it. I wanted to learn why, and have received a lot of great responses!

[1] https://idioms.thefreedictionary.com/be+sold+on+something

> Supports TypeScript out of the box.

> Ships only a single executable file.

> Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).

Taken all together instead of individually, Deno is clearly designed to produce more secure and maintainable codebases than NodeJS over longer periods of time and team turnover. All of these "by default" additions better ensure a common, high-standard baseline for any arbitrary Deno codebase over any period of time.

Individual developers often tend to focus on "how does this help me/improve my workflow right now?", instead of thinking like a CTO and focusing on "how does this technology make our IT systems more robust to long-term maintenance, developer turnover, and security threats?".

Secure by default means you shift security from the developer team into the framework. Say your original security-focused developer team attritions over time, and due to a software engineer shortage you're forced to hire less experienced or less security-oriented folks.

Even if you end up with a new team more oriented to "move-fast-and-break-things" than secure-by-design/correct-by-construction, your framework still provides a minimum security baseline they can't intentionally or accidentally violate.

That works in reverse too - say you're a new startup that can't afford to hire the best of the best yet. If you choose a secure-by-default framework like Deno, you're getting security and correctness from the framework for free, rather than having to pay a premium for developer talent capable of that.

Typescript instead of Babel means that all Deno codebases everywhere will use the same language, one that provides better correctness and security guarantees than most Babel options.

Built-in dependency-inspector simply makes that function more available and apparent to developers. Maybe useful for new entry-level folks, not so much for more experienced ones.

And I thought the value of a built-in code-formatter was demonstrated by Go with gofmt - all Go codebases everywhere are formatted the same way, making it easier for Go devs to get up to speed with a new codebase.

One of things that used to really annoy me about both Rails and Nodejs was how they were not secure-by-default and left certain security details/holes to be implemented/fixed on an ad-hoc basis on every new project by individial dev teams.

But the whole point of a framework is to provide common solutions to such common problems that all projects incur, so the dev team can focus on the custom and creative parts of the app, the value-added parts, the competitive edge. It's great to see Deno and others doing this.

It's not that I disagree with Dahl on most of his recognized mistakes (though some I do, most especially that a standardized, embedded packaging system was a mistake, despite the legions of warts of NPM), it's that most of these mistakes feel like little nits or one-time costs that just don't bother me at all in the Node world.

I mean, it feels like the best thing going for Deno is out-of-the-box TypeScript support, but with Node it's trivial to have a template project that integrates all this for you, then it's 1-and-done. Perhaps the other thing I like about Deno is it separates the standard library into its own package instead of being part of the Deno-runtime version, but again, this difference is definitely not enough to make me switch.

Could you not just build a URL loader and cache for importing in Node.js? Could sandboxing not just be a flag in Node.js? Do you really need TypeScript built in?

I'm not going to throw years of my and other's work away for some gimmicks. It's just a bad investment.

There are open PRs on node for the first two parts ^^ It's 100% doable.

  - TypeScript works out-of-the-box without configuration
  - includes modern browser APIs like fetch() without needing to import additional dependencies
  - The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces
  - The Deno standard library[1] reduces the need for 3rd party dependencies, since it covers a lot of cases where one would be needed

  [0]https://doc.deno.land/builtin/stable#Deno.readTextFile
  [1]https://deno.land/manual/standard_library

FYI, Node has Promise-based APIs for all filesystem APIs. Node also supports ES modules that use top-level await.

If you create a file `test.mjs` and put this in it, it'll work:

    import {readFile} from 'fs/promises';
    console.log(await readFile('foo.txt', 'utf8'));

Deno goes in the wrong direction. It's a TS fanboy invention in search of a problem.

And I say that as a TypeScript fanboy.

Hardly. TS would have 1% of the adoption without JS.

> creator of Node, started Deno

Kudos for Dahl for his practical, very successful project Node.js.

I’m curious what you think is the right direction Deno should have taken.

The image on the post is this - https://deno.com/deno-on-mdn/table.png

This is the image used in og meta tags - https://deno.com/deno-on-mdn/header.png but this one includes a visual cue and it becomes immediately clear that Deno is added to the chart

0: https://developer.mozilla.org/en-US/docs/Web/API/console/log

https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder...

https://developer.mozilla.org/en-US/docs/WebAssembly#browser...

It's worth noting this isn't Node's fault: most Node APIs existed before there were browser equivalents and adding browser compat now is much harder for Node than for Deno which is starting from scratch.

fetch: Browser fetch didn't exist when NodeJS introduced its http built-ins. Many NodeJS libs are built on top of http built-ins, so replacing them would be a nightmare. Adding browser fetch on top of the existing http built-ins would similarly just give NodeJS a massive API surface area with cconfusingly duplicated functionality.

ESM + web import semantics: NodeJS was part of the "commonjs" movement that invented Javascript module importing. Module imports are an incredibly complex problem and hard to get right. Browsers took the hard-learned lessons from commonjs & nodejs and redesigned better modern APIs. NodeJS has been slowly trying to add support for the much improved browser web import semantics, but doing so while maintaining backward compatibility with their radically different commonjs APIs is a nightmarish challenge (they're working on it though, progress is good).

WHATWG streams: similar story to the import/commonjs situation. NodeJS basically "invented" streams in JS, and the WHATWG API is a newer design based on NodeJS lessons.

WebCrypto: Sibling comment is incorrect here actually: NodeJS & Deno both support this[0]

[0] https://developer.mozilla.org/en-US/docs/Web/API/Crypto

- ESM modules are challenging to mock or monkeypatch

- I feel like the ESM implementation is more "magic" than require. I definitely would say I understood require better.

- Many esm features are still behind flags e.g. importing a .json file.

I'd guess that by the time Deno gets really good, Nodejs achieved same level of compatibility.

> I definitely would say I understood require better

ESM modules are in many ways "harder" to use than commonjs, but I think this comes down to something slightly intangible but very similar to the static-typing -vs- duck-typing discussion (duck-typing is more obviously intuitive and quick-to-do-what-you want, but static-typing has more wide-reaching architectural benefits for scaling projects).

CommonJS is a more "intuitive" design: what you might expect someone to design first-time-around. ESM is a more thought-through design: the initial "hurdles" to its use bring long-term benefits.

> ESM modules are challenging to [...] monkeypatch

This seems like a feature though

> I feel like the ESM implementation is more "magic" than require

How so? I'd say I feel the opposite.

> importing a .json file

Is this supported by browsers or is it a NodeJS extension?

This is a node extension. It is coming to browsers in form of import assertions. See https://github.com/tc39/proposal-import-assertions

Just for anyone tracking progress, the actual feature proposal is here: https://github.com/tc39/proposal-json-modules - the assertions proposal is just a security check on top of such modules.

What's the point of implementing APIs like WebGPU and localstorage in a non-browser environment? I get WHATWG streams, esm, fetch and WebCrypro though.

- 1: https://github.com/WICG/import-maps

Localstorage is admittedly a bit niche, but works well as a way to bypass the need to get generic read/write permissions for the filesystem for a config file. (Deno implements a permission model similar to the web where you start with nothing and must request / have pre-granted access to resources like files/network/env/subprocess, and this access can be granular to specific files/directories/host+port combos)

> The WebGPU API gives developers a low level, high performance, cross architecture way to program GPU hardware from JavaScript.

> GPUs allow programmers to make some numerical algorithms highly parallel. This is useful beyond rendering graphics and games. Effective use of GPUs in Machine Learning has enabled more complex neural networks

- https://deno.com/blog/v1.8#experimental-support-for-the-webg...

You could save the state of a discord bot across restarts for example.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Edit: as others have pointed out, APIs that are implemented in Node.js are listed on MDN.

OK?

Reminds me of how Rome is doing.

You can’t reinvent this stuff over and over again and ignore that at the end of the day there are people who use this stuff to make money. Node.js is already good enough.

I think if people end up using Deno it’ll be because of things people need to use that you can’t get or polyfill into Node.js today.

But it won’t be because of new behaviors.

Another way to say that: You can't build new awesome free stuff because other people already use your old awesome free stuff to make money.

Sounds ridiculous.

They can and should keep making new stuff, for the next generation of people and apps, whether to use it or not is an individual/organizational choice.

What you’re saying sounds ridiculous.

Or are you still using WordStar on CP/M, so you don't care about all that progress stuff?