1. 25
  1.  

  2. 8

    I say this introduced by Ryan Dahl (who created node.js) in his presentation:

    10 Things I Regret About Node.js - relevant Lobsters discussions. The presentation is a both a great retrospective/honest assessment and introduction to Deno.

    Good to see this still making progress! I don’t work with Node, but think this is a good competitor for those sorts of things (Javascript/typescript server side)

    1. 8

      Really unclear what this is. The title says “browser-like” but the example looks a lot more like a web server? What does “browser-like” mean?

      1. 5

        I watched this talk when it came out, so I don’t remember everything about it.

        But one thing that makes it more browser-like is that it retains the isolation that v8 already has in the browser, so you can run untrusted code.

        node.js has no isolation – any node program or snippet you eval() can access all the OS APIs to write files, fork processes, etc.

        But he said that this was a mistake and deno retains the ability to run untrusted code. In other words, deno is meant for mobile code, but node.js is not. That’s one reason it’s more browser like, but there could be others.

        I agree that the web page isn’t very clear.

        1. 5

          From the deno manual:

          Deno aims to be a productive and secure scripting environment for the modern programmer.

          Deno explicitly takes on the role of both runtime and package manager. It uses a standard browser-compatible protocol for loading modules: URLs.

          Deno provides security guarantees about how programs can access your system with the default being the most restrictive secure sandbox.

          1. 3

            I feel like the focus has slightly shifted since the first introduction of deno during his talk about what he regrets from Node.js.

            The “package management via URL” puzzles me quite a bit. The recent apt vulnerability has proven that relying only on HTTPS to secure dependency downloading can be a mistake (if I recall correctly the attack).

          2. 3

            I think it’s meant to be an environment that can run made-for-browser JavaScript programs. Or maybe an alternative to Node.js that is “closer” to how the browser works. There’s an introduction, but it doesn’t convey its purpose well enough.

            1. 2

              Discounting arguments in the style of “I only know this one language so I have to use it everywhere” – what’s the actual use case for this?

              I know my point of view is extremely limited, but to me JavaScript is something you want to use, e.g. for getting the current width of the viewport, or adding a DOM element without having to talk to the server. You want it for its abilities to do things in the browser. So when you remove the browser, what is left there? Genuinely curious.

              1. 1

                Apart from not knowing other languages, here are some other reasons to use JavaScript on the server or in a stand-alone program, whether with Node or Deno.

                • You want to run the exact same code on the server and in the browser, so you can be sure they get the same results.
                • You think that mentally switching contexts to a different language and different libraries slows you down more than the other language speeds you up.
                • You need to use a library that has only been implemented in JavaScript so far. Or the JavaScript library is far easier to use than the libraries for other languages. (I don’t know of any examples, but there are probably some domains like this.)
                • You are writing a tool to analyze/reformat JavaScript, which could be easier if you have the ability to convert analyzed values into native values.

                Node and Deno are also suitable runtimes for TypeScript and for JavaScript with Flow types, which might lessen the advantages of other languages.

                1. 1

                  Thank you! Some of your points resonate with me more than others, but I appreciate how clearly you laid it out. I’m not surprised to discover there are indeed good reasons to run JS outside of the browser, and a non-browser JS implementation is only natural!