Deno on MDN | Hacker News Reader

Deno on MDN

deno.com

441 pointsmonstermachine194 comments

Can someone "sell me" on Deno? I'm still not sure why I should be interested in this versus for example NodeJS. Most of the features it lists seem rather dubious.

> 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.

Honestly for me it is:

- Follows the ecmascript standard and supports browser apis

- No npm, no Microsoft lock-in

- So far, no political bs like node has had

Is Deno ready for production?

What limitations have you run into?

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

> Is Deno ready for production?

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.

No deno native MS SQL support

> No npm

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.

> You still need packages

Yes but with ES modules you can just import them straight into the code and there is really no need for a package manager.

> 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.

This may be somewhat true. However I am not using typescript so I am not really sure about this.

My point is not really tied to the language typescript which I am sure will continue just fine. What I am much more worried about is all the packages hosted on npm. At any time Microsoft could do something to restrict it in ways I can't control. Highly unlikely that something extreme will happen perhaps, but I don't trust Microsoft enough.

For example, I could easily see them forcing everyone to use github for node packages in the future etc.

> you can just import them straight into the code

"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?

From anywhere on the internet.

> So, how does deno help?

By decentralizing the package hosting.

> From anywhere on the internet.

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.

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

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.

> Litterally anywhere. On Github, on the Deno webpage, in a slack chat message.

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.

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

Well yes.. but usually that is true for npm packages as well when one search for documentation or source code.

> Deno is not a browser

It tries hard to immitate the browser context and does so very successfully IMO.

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

Well, that was just an example. I am just pointing out the concept of decentralization. You don't have to be reliant on npm and their systems.

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

Since each dependency is an url, it will fetch all deps and download them in order to cache it. Pretty much how npm works as well, except that npm in reality only fetches from the npm registry even if I think it's possible to add github repos to the package.json.

You also don't need a package.json which is great especially for smaller scripts.

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

It's not inherintly bad. I personally prefer to not be reliant on an american mega corporation which is known for it's anti-competitive practices and woke agenda. Their interest will certainly not align with mine.

> 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

Well in that specific case you would need to download the entire tree and host it yourself. Then you can change the url.

I mean, if you're happy with node and npm. Continue to use it. You don't have to switch to Deno but I am convinced it's the future for server side javascript. It's just... nicer in general.

> but usually that is true for npm packages as well

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

> You still need packages

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

> Which you import just like you would in a browser.

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

> Import them from where?

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.

> A url.

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?

Why do you need to be sold on Deno?

I imagine the parent is confused as to why people care about Deno since it gets a decent bit if coverage on HN.

It's a different question why something is popular on hackernews or why someone should use something. Deno is interesting and worth paying attention to, that does not mean someone should be sold on it or build something with it (yet?).

But clearly people are using it. GGGP is asking why people are choosing it. It’s a very straight forward conversation and I feel like you’re nitpicking word choices.

I don’t see this as a good faith conversation. It’s one thing to ask why people are using something, another thing entirely is to get people to convince one to use it. Particularly when the post already starts with a few statements of not liking it.

It's just an idiom[1]:

> 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

It doesn't have to be server software. I created a cli tool with Deno so that it could run as a standalone binary. It runs a lot faster than if it were built with node and any user without node installed could still run it.

I haven't worked with JS for a while so I'm not really up to speed on modern Deno and Node but can't you also package a node cli tool as a binary? Also how can Deno run a lot faster? I would imagine it at least suffering from a startup time hit due to the TS compiler. Maybe someone can explain?

Transpiling TS to JS on startup does incur a cold start penalty, you can minimize it by using the `--no-check` option to transpile with SWC instead of TSC but it's still there. On subsequent runs though, it'll start up instantly because the JS is cached locally after transpiling (you can even trigger this step yourself with `deno cache`)

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.

> These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages

Very cool, thanks for the detailed answer.

It's standalone in a sense you end up with a single executable, but deno is embedded with your code. A `hello world` example is more than 50MB stripped.

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`.

That's not really different than how most scripting languages provide compile or application delivery features (whether built in or through a module). You're right that it isn't actually "compiling" as most people would expect that to mean in a programming context, but given that packaging into a single executable is generally what they're actually looking for, that's usually an acceptable distinction.

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!

So, it's still linked against glibc and libgcc from what I can see almost all the following are from glibc):

    $ 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)

But honestly, that's pretty minimal. Just over 80 MB for the base to not have much in the way of dependencies seems pretty good. And given that library extensions are supposed to mostly be done in Rust (if that hasn't changed), those are statically linked by default as well, so that will hopefully cut down on accidentally introducing dependencies from the system it's built on also.

I get the feeling it’s just meant to be a nicer development experience by including more out of the box. I tried it briefly and was impressed by how easy it was, it felt like I was in another language’s ecosystem rather than the complex duct tape approach JS has become infamous for. I think as it matures, it will help increase productivity and decrease complexity for new projects.

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.

Deno has replaced shell scripts and Java in a lot of places for me.

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.

This sounds like something you can get with other languages which compile to native x86_64 or arm or whatever - specially the single executable concept is ages old and predates the entire internet. Why use js, which is slow?

There is always something that doesn't fit either the use case or the aesthetic sense.

> 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.

This just don't make sense. People do scripting in sh, bash, python, etc all the time. Why not js?

Using Java for shell scripts (using a shebang) is on my todo list. IIRC, there's a GraalVM or Truffle or something interpreter that'd work.

> Types

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.

Typescript definitely has some flaws but it also has some really powerful features that aren't found in any other type systems, like the ones you listed.

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 ..."

> There are so many better options if you want a good type system

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.

> TypeScript doesn't even come with ADTs

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

They need to be first-class. Not means the ergonomics aren't great and it won't be the developer default because it requires a library. It's not good enough considering how fundamental these two are in many languages (it's even in Java now)

> 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!

So TypeScript is designed for the internet, and languages with good type systems are not.

This has nothing to do with the GP's comment, which was about local scripting (replacing "shell scripts and Java")

> Deno has replaced shell scripts and Java in a lot of places for me.

> - 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.

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

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

WSL? Are you asking...is software for one operating system able to run on another operating system without installing a compatibility layer(if it exists)? If so, the answer is "no, of course not".

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

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.

> wrt Java

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

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

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

For me the main selling points are:

- 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.

npm is hot garbage. If it fixes npm I'm all for it.

I would say, it doesn’t really fix npm. It has its own centralized npm repo, called deno land, and it’s own package.json, called deps.ts.

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.

This something I really don’t understand about Deno. I feel like I must be missing something.

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.

yeah, it's a bit awkward and you have to dig through the docs to find it. We're thinking about making it the default behavior.

Please do! I think that would be a big win.

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?

If you want to use locked version deps from VCS you point to a specific tag, not a branch IIRC.

deno.land/x is _not_ a central registry. It's something we maintain as a convenience to the community, but we actually go to great lengths to make sure it doesn't receive preferential treatment from the CLI. Importing modules from nest.land, skypack.dev, esm.sh or jspm.io is common in the ecosystem and is something we're looking to keep encouraging.

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.

Thanks for the response. And thank you for clarifying that there is a larger ecosystem of package repositories, and that Deno does not give preferential treatment to any. In theory npm can do the same, but of course there is official support and community gravitational pull around a single service.

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.

> 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

> It's also pretty easy to vendor in your dependencies

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

This will pull both the package and all its dependencies. It will create a lock file and will essentially lock the version. There are additional ways to specify the exact versions, and version ranges for packages and dependencies.

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 disagree npm is hot garbage. I'd say it's more like "smoldering garbage".

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 am struggling to understand how Deno is supposed to do that. To me it seems like they are re-inventing the package.json What is the difference ? https://deno.land/manual@v1.13.1/examples/manage_dependencie...

Perhaps an alternative way to sell this might be that Deno is authored by the original author of node. He introduced Deno at a talk "What I regret about Node.js" and presented Deno as the product of his lessons.

I've now done two small web services in Deno, both are in production serving very small amounts of requests (i.e. tens per week scale).

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.

> I think Node.JS is the dumbest thing to ever happen in IT history

Did you already forget about PHP? :p

1 - it is not just server software, but general purpose usage.

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.

[deleted comment]

This is something often overlooked by fans of typing. On the surface it may appear to some as being strongly typed, but it's a mirage [1] and frequently requires a lot more lifting, e.g. writing specific typings to work around shortcomings, just to make the types play nice together. That's not a feature of a strongly typed language, it's a feature of statically type-checked languages or schemas.

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

I didn't like TypeScript when writing frontend only code, because the the iteration speed is just so fast in the browser.

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.

Typescript is miraculously productive on the front-end as soon as you've got people writing at different "layers"—someone writing a frontend library, someone else handling state and actions, someone writing components for re-use, someone making it look pretty and using those components. You can be sitting right next to someone using code you wrote but rarely need to discuss it because the types communicate everything so damn well.

I've seen this take so many times an I simply don't get it. The notion that TypeScript can't be (some form of) strongly-typed because Javascript is (some form of) weakly-typed is just silly. CPUs are entirely weakly typed in this sense and this doesn't impact the typings of languages built on top.

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.

> I've seen this take so many times an I simply don't get it.

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.

The definition of a strongly typed language has been well-cemented for some time

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

https://en.wikipedia.org/wiki/Strong_and_weak_typing

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.

All typing is a mirage, enforced at various levels by various tools, whether that's a compiler during the build or a VM during runtime.

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

It's no more, or less future-proof. And as much as counting productivity of a programmer in LOC doesn't make any sense, your take on typescript does not either. It's extra security that matters. Typescript just prevents you from shooting your foot off (btw. show me, even small program, where Typescipt added 50% LOC)

1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? 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.

> Python is much better as 'general purpose' right now

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.

1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's.

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?

> yeah but mostly node is used as a server software.

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.

Why ship node_modules? Because you want to ship the complete app. At least rsync comes to the rescue for quick deploy of 10000 tiny files remotely.

That seems incredibly wasteful and time-consuming.

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.

> personally I don't see why you'd want to use anything other than Typescript right 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.)

> 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.

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.

> Not to mention the majority of Node and FE developers who continue to use JS.

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

I've never used TypeScript. I've also never heard of this survey before, and I certainly didn't fill it out. I don't think these two facts are unrelated—according to their data, the vast plurality (48%, almost a majority) of the people who filled out that survey did so because they were on the mailing list for it. It's by no means a random or representative sample of the community. People who are more interested in surveys & new technology and are more likely to sign up to answer future surveys.

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.

I’m curious on how you manage large code bases without some kind of static typing and other checks that typescript provides, like object properties, etc.

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.

I have used TS in the past and want to use it more in the future, so I'm probably counted in that 78%... but for the vast majority of projects I'm not using it. Based on most comments, questions, examples in lib code, etc. I'd say that the number of people using TS is waaaay less than 78%.

It supports typescript, but you're not required to use it.

Reason, ClojureScript are separate languages with their own computation models and conventions. They are designed to have their own ecosystems rather than integrate smoothly with the JS ecosystem.

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 only have experience with ClojureScript, there the npm ecosystem support is good thanks to recentish improvements, at least for consuming, and we routinely use libraries from there. Usually encapsulated by some ClojureScript shim to keep functional interfaces (and kebab case!).

ClojureScript (and the other mentioned languages) really are in a different category than TypeScript. You can think of TypeScript as a linter for JavaScript that you help by adding some annotations to your JS, rather than an entirely different language. Deno merely strips those annotations for you before executing the remaining JavaScript.

The TS language semantics would seem to preclude a stripping based implementation, no? Eg generics seem to be a whole new area of semantics [1].

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

Generics in typescript do not affect codegen, they are only visible to the typechecker.

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.

What about this article, which says the type level programming features constitute a turing complete system: https://mjj.io/2021/03/29/type-level-programming-in-typescri...

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".

See the last paragraph of zarzavat's comment :) They wouldn't be added today, and they aren't widely used any more (they have non-codegen alternatives now). In other words, breaking changes in semantics shouldn't be a worry any more, since the TS team has consciously decided to attempt to avoid them a few years ago.

> feels like TS is where its at.

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.

> personally I don't see why you'd want to use anything other than Typescript right now

A desire to not have IP coupled to Microsoft and a desire to put the burden/discipline on the self to ensure clean API design versus using TypeScript as a crutch to do it for you. In my experience, writing JavaScript code that's conscious of types/inputs/etc. is far easier (and more productive) than maintaining a TS codebase and all the trimmings that come with it (i.e., dependency on build tools, frameworks, etc). A lot of hidden costs.

How are you conscious of types without any tooling? And if you use tooling, then what's the difference?

When you design your API/write functions, you just ask "what is the type in play here (e.g., a string, int, etc)?" and then consider what—if any—issues that may cause and write code against it.

For example, JavaScript default args are really helpful for avoiding type errors:

const nameString = (name = {}) => { return `${name.first} ${name.last}`; };

Here, because I set a default expected type (technically speaking), I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case, or, write a test to call my attention to the problem (often unnecessary because the "bug" is a design issue).

Not to mention the Typescript parser can be configured to parse JSDoc comments for compiling an index.d.ts file for external users if need be

  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.

Yes? And I understand why you want to use it, I'm just saying that it's not always necessary (i.e., some of the dogma around it is unwarranted).

> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case,

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.

IMO, same thing. If I see that, I'm going to know what to fix. Still not a sell that I need to add in TypeScript. I get the why, but it's often overkill.

...or just use typescript and get red squiggles in your IDE (...or when compiling if not using and IDE) and you don't have to go manually check your UI or write a unit test to make sure you provided the right type. Your approach sounds totally unscalable beyond a small project to me - you can't go manually eye ball your entire UI on every change.

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

So you do it manually? That's exactly what Typescript was created for, to use tooling and automation to handle these and it's been repeatedly proven to reduce bugs and increase productivity because of it.

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.

How is TypeScript a crutch for API design?

API meaning data API/structure, not a public/restful API.

The more I learn about how it imports external/third-party code [1] the more I like it. It's got none of the hangups of NPM. No package.json nonsense (there are great script runners if you need them), and no cruft when importing external code (e.g. no need for yarnclean). The registry they do maintain is unique and immutable, which I was not sold on until I had this discussion [2]. I do still think they need some more guidance around how that works, and some contingencies in the event of bad actors, but it's just as good as NPM's registry imho. Native TS is a nice convenience for projects which call for it, and compiling is much more streamlined than bolting it onto a project yourself. It's worth noting that it does support plain JS, just the ESM flavor. And last but not least is the stdlib, which roughly aims to prevent the need for a million one-line packages spread out across the registry. Network throughput performance is impressive to say the least, and with leveraging Rust I can only see that getting better. The more I learn about Deno the more that I'm liking it.

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

It's quite a bit worse than npm.

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.

> It's quite a bit worse than npm.

That's a rather subjective take.

The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.

Aren't most takes on here subjective? I don't think we label most posts with "Only my opinion, but..." event though that applies to almost everything here. Anyway...

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

I was just having this discussion with a friend of mine this morning. How is this not the exact same mistake Go made when it was released in 2015? They spent years and years walking back the issues that "go get" had in favor of a real, actual package manager. I know Deno encourages users to use versioned imports, which works around some of the bigger problems that Go had, but creates a lot more problems in terms of upgrading transitive dependencies. How is this a step forward?

Ignoring hard problems for short-term gains is an easy way to get market share.

We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have noticed we have support for import maps[1]. These elegantly solve the issue in a way that also works in the browser. No node_modules needed :-)

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

Import maps are great if you know all the mappings you want to make.

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.

It'll eventually evolve into npm-but-different once Deno gains more adoption and its users learn they need a real package manager. And the cycle continues.

That looks like the output of a package manager (like a cabal freeze file), but if that's all you got then you don't have a package manager yet.

projects like `trex` [1] take the heavy lifting out of the equation, and are nicely compatible with a lockfile. This may feel familiar, even somewhat similar, but after using it for a short time I state with confidence that it's not a package manager. This paradigm is enjoyable.

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

Yes, it seems like a very similar mistake to me: https://github.com/denoland/deno/issues/4574#issuecomment-62...

>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?

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.

Which slightly incompatible version of TypeScript though?

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.

That's always a concern, though. Node has breaking changes, too.

It's a somewhat relevant concern, but also less so because breaking changes in TypeScript are usually semantic (type-checking) ones and most of the times make it error on bugs (i.e. code that hopefully isn't in your codebase already, and if it is, you'll want to take it out). Deno doesn't do type checking, it just strips TypeScript's type annotations, which they're far more careful about breaking.

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

It was made by the creator of NodeJS and fixes many issues he considers to be mistakes. Do you like NodeJS? This is NodeJS 2.0.

I've seen the original Dahl post about his mistakes with NodeJS, and why he wanted to do Deno, and to be frank, I'm not convinced.

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.

Deno feels like past the peak technology to me. You've got years and years of labor put into the Node.js ecosystem, and then the guy comes out with something that totally drops all of that for some gimmick features.

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.

> 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?

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

Seems like Deno will have some great competition then. I'd rather slowly implement such functionality than dump everything.

> 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.

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`.

>> 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.

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.

See comparison here: https://deno.land/manual#comparison-to-nodejs

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

I think it probably makes more sense if you’re in the Node universe (and Dahl created the thing). If your window for the state of the art is… the range of what Node and its immediate surroundings can do, then Deno probably seems like a marked improvement. While people (well, me) look from the outside and think: This is how far you moved on a clean slate? Then you consider waiting for the ecosystem to mature (considering the mess the JavaScript has been and has only recently been slowing down) and go, “Ehh.”

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

> the first thing any project is going to do is enable all of that

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?

Could you not reply this way?

Not sure what you mean; is the formatting hard to read, or do you mean the content?

I think you should look at it the other way around, assuming you are already using a mature version of Deno it most probably wouldn't make sense to switch to something like NodeJS:

- 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.

Browsers generally are running code that came from a package manager these days. But devs expect to run a file server for their browser code. Do Deno devs need to expect to run a separate file server for their Deno code?

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

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.

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

> 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.

Honestly what world are you living in where Flow is even remotely relevant in 2021?

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

I think your bias is showing.

I had a very similar reaction at first (the exception being first class TypeScript support). I’ve since come around to being very interested in Deno and curious to use/support it more. Here’s what’s brought me there:

- 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.

The module stuff is what has me looking at it. We’ve got a bunch of Node services that are relatively small and single purpose. Using tsnode, adding a build step, tinkering with ESM/CommonJS to work within the monorepo TS project reference graph... it feels like a huge PITA with mostly unnecessary overhead.

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.

One thing that I think is often overlooked when it comes to Deno is how the combination of secure defaults, web API compatibility and the dependency loading system can essentially eliminate the need for actual deployment builds and containers making it a great candidate for a truly open source and non-proprietary serverless platform.

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.

Deno looks great to glue together CICD work

I'm a long-time Node user but decided to use Deno for a personal project and found that it's is a pleasure to work with. Some highlights:

  - 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

I haven't yet used Deno in a commercial product, but I believe I will in the future because Deno seems ready for primetime.

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

> - The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces

require("fs").readFileSync("hello.txt").toString() // toString because it's a buffer by default

A Promise-based API doesn't block the event loop, but a synchronous one like fs.readFileSync does. Their usage might look similar but their semantics differ vastly.

Fair enough. OP was talking about intuitive non-blocking APIs and I just considered "intuitive".

Do you know if Deno chose to use strings instead of buffers to be more consistent with the browser? I know buffers can be faster, but overall I like that readTextFile is returning a string here. I suspect most use-cases ultimately want to handle the output as a string.

Deno uses uint8array (pretty much Nodes Buffers (Node Buffers subclass UInt8Array these days)) for almost all methods. For example Deno comes with `Deno.readFile` which returns a Promise<UInt8Array>, but they include the special case Deno.readTextFile because of how common it is to convert the contents to a string.

Ah of course, that seems obvious in retrospect. Thanks for clarifying it for me!

> The Deno-specific APIs (like Deno.readTextFile()[0]) are Promise-based and have intuitive interfaces

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'));

https://nodejs.org/api/fs.html#fs_filehandle_readfile_option...

Thanks—I didn't know about fs/promises

The fundamental advantage of TypeScript (vs other languages like Scala.js) was that it could easily leverage the entire Node.js (EDIT: JavaScript) ecosystem and vice versa in a very smooth way.

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.

TS by itself is a great language even without the JS support. The Node ecosystem has a lot of shortcomings which Deno aims to solve. I disagree with your assertion that Deno is a fanboy invention in search of a problem. If the creator of Node, started Deno, then obviously there is some merit to his thought process.

> TS by itself is a great language even without the JS support.

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.

There is still a lot of friction using Typescript for just about any Nodejs project. Things have definitely improved, but it is still a far cry compared to first class language support.

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

I don't know why but I had to read this blog post about six times before I realized that its about Deno being added to the compatibility chart (far right in example) shown on MDN.

I noticed something odd.

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

I need something for Monday mornings that shows me the content of the OG tags on articles so my lizard brain has an easier time.

This is really cool! Can anyone explain why deno has made it to MDN but node.js has not?

I believe it's because Node.js has never made an effort to implement web APIs nor has it been a goal of the project.

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

Worth noting, informationally, it is a goal of the Node.js project to implement web APIs. Deno is just way ahead as it doesn't have to worry about backward compat: it's a much tougher challenge for the Node.js guys, but they are working on it.

nodejs is there as well, ie. [0]. Maybe it's missing for apis they don't provide? ie. fetch [1] does not list nodejs.

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

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

Node is on a number of MDN pages (e.g: [0]). I think it's just APIs that Deno supports and Node doesn't (e.g: fetch) that are linked here, which is why it's not in their support matrices.

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

setTimeout is linked here, https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWor..., and shows partial support (with explanations) for Node.js.

Also see TextEncoder or WebAssembly which shows the version support of Node.js and others

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

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

node is on MDN for all browser APIs it implememts, there's just not many of them. Deno has much higher browser compat.

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.

> Deno has much higher browser compat.

Is this a fact or a personal feeling? Any links to back up this statement?

This is a fact. Import maps, fetch, ESM + web import semantics, localstorage, WebGPU, WHATWG streams, WebCrypto. Deno runs the shared web platform test suite: https://deno.co/wptfyi. You can also just look on MDN now and see which APIs are implemented in Deno compared to Node :-)

Is import maps considered an accepted proposal [1]?

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

Local storage let's you save state across process restarts and session storage let's you share data across worker threads

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

About webgpu

> 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...

Implementing WebGPU allows you to make use of GPU resources on the server (from rendering to more compute focused)

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 sibling commenter covered the list well. To go into a little extra context on the reasoning:

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

I use esm in nodejs >= 14 since roughly 6 months and I'm almost back to where I was with CommonJS. Problems that I have:

- 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.

> ESM modules are challenging to mock

> 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?

> 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

Oh, good to know! I hadn't heard this.

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.

Because Node is the new IE.

That is great, good work you guys!

Imagine building a business and putting years of labor into a suite of intellectual property which makes you hundreds of thousands of dollars then they guy who built what your business runs on came out with something new to replace it and said hey now you can import using URLs and by default have access to nothing unless you ask for it.

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.

Stop building new stuff?

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.

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.

If I told you I’m giving you an annual $600,000 budget to build a small team and write software, and you chose Deno and had to reinvent JavaScript libraries that already existed for years, I’d fire you for being negligent with funds.

What you’re saying sounds ridiculous.

Good thing the MIT AI Lab couldn't fire RMS for being negligent about not continuing to maintain TECO Emacs, which so many people were using every day all over the ARPANET for years, and going on to learn from its mistakes and making Gnu Emacs with LISP implemented in C instead of TECO implemented in PDP-10 assembly.

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

Did you mean to post this to a discussion about Perl/Raku?

Reply on news.ycombinator.com