9 ms·

Hey, Bartek from deno.land here. I'll be more than happy to answer your questions about Deno and its development.

nikisweeting 6y ago
Last time I tried deno there was some friction with depending on npm packages that didn't natively support deno without vendoring, is that easier nowadays? Can we seamlessly import anything from npm inside deno-run code and use the deno stdlib side-by-side with node_modules code? We love the Deno direction and would even willing to donate $ to grow its development, but for us it's pretty much non-starter to switch to a different runtime until we can use the wealth of packages available on npm without any additional friction. The Deno docs here almost seem to purposefully avoid answering this question: https://deno.land/manual@v1.6.0/examples/import_export https://deno.land/manual@v1.6.0/examples/import_export
- bartlomieju 6y ago
  That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node. It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting better.
  - nikisweeting 6y ago
    Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.
    - jimmyspice 6y ago
      why not use artrifactory or similar proxy so you always have a local mirror?
      - nikisweeting 6y ago
        That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.
        wperron 6y ago
        to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really) The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from
    - bartlomieju 6y ago
      > We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with a path you can tell Deno to change that cache dir. And these files are cached indefinitely; Deno will not try to fetch them again on next run (unless you opt into it with --reload flag).
      - nikisweeting 6y ago
        Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.
  - galaxyLogic 6y ago
    That is interesting. Does it mean I will be able to run my Node.js program on Deno? That would be really huge in terms of letting users migrate from Node.js to Deno.
flowerlad 6y ago
OK, so what is Deno? How is it different from Node? Why did you make Deno given that Node exists? Looks like Deno can run .ts files without first compiling to .js. What are the other benefits?
- bartlomieju 6y ago
  Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno has built-in permission system that by default runs your code in full sandbox allowing to opt-in into breaking out of sandbox (eg. to read a file from disk) - As you've mention Deno can run .ts files without explicit build step - Deno comes with a full toolchain in a single binary (formatter, linter, test runner, bundler, doc generator) [1] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
  - mpoteat 6y ago
    Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel. I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.
    - bartlomieju 6y ago
      > Personally I appreciate being able to choose my linter, compiler, dialect etc. I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users. > I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work. Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over. [1] https://deno.land/x/std@0.80.0/node https://deno.land/x/std@0.80.0/node
christophilus 6y ago
Last I looked, there was no clear crypto story for Deno. Has that improved, or are there any concrete plans for it? Deno was really quite nice when I kicked the tires, but didn't seem quite ready for prime time web development with no crypto functions.
- tracker1 6y ago
  Not yet[1] likely to see WebCrypto first and/or something similar to Node's crypto library. You could probably get away with wasm build of a C/C++ or Rust library if you don't mind getting dirty. 1. https://github.com/denoland/deno/issues/1891 https://github.com/denoland/deno/issues/1891 edit: partial webcrypto/wasm option already available https://deno.land/x/god_crypto@v1.4.1 https://deno.land/x/god_crypto@v1.4.1
the_gipsy 6y ago
What's your plan for importing other typescript packages, natively? Last I remember is that every project/library has vastly different tsconfigs.
jbirer 6y ago
What are you wearing right now?

Last time I tried deno there was some friction with depending on npm packages that didn't natively support deno without vendoring, is that easier nowadays? Can we seamlessly import anything from npm inside deno-run code and use the deno stdlib side-by-side with node_modules code? We love the Deno direction and would even willing to donate $ to grow its development, but for us it's pretty much non-starter to switch to a different runtime until we can use the wealth of packages available on npm without any additional friction. The Deno docs here almost seem to purposefully avoid answering this question: https://deno.land/manual@v1.6.0/examples/import_export https://deno.land/manual@v1.6.0/examples/import_export

bartlomieju 6y ago
That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node. It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting better.
- nikisweeting 6y ago
  Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.
  - jimmyspice 6y ago
    why not use artrifactory or similar proxy so you always have a local mirror?
    - nikisweeting 6y ago
      That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.
      - wperron 6y ago
        to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really) The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from
  - bartlomieju 6y ago
    > We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with a path you can tell Deno to change that cache dir. And these files are cached indefinitely; Deno will not try to fetch them again on next run (unless you opt into it with --reload flag).
    - nikisweeting 6y ago
      Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.
- galaxyLogic 6y ago
  That is interesting. Does it mean I will be able to run my Node.js program on Deno? That would be really huge in terms of letting users migrate from Node.js to Deno.

flowerlad 6y ago

OK, so what is Deno? How is it different from Node? Why did you make Deno given that Node exists? Looks like Deno can run .ts files without first compiling to .js. What are the other benefits?

bartlomieju 6y ago
Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno has built-in permission system that by default runs your code in full sandbox allowing to opt-in into breaking out of sandbox (eg. to read a file from disk) - As you've mention Deno can run .ts files without explicit build step - Deno comes with a full toolchain in a single binary (formatter, linter, test runner, bundler, doc generator) [1] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
- mpoteat 6y ago
  Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel. I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.
  - bartlomieju 6y ago
    > Personally I appreciate being able to choose my linter, compiler, dialect etc. I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users. > I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work. Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over. [1] https://deno.land/x/std@0.80.0/node https://deno.land/x/std@0.80.0/node

christophilus 6y ago

Last I looked, there was no clear crypto story for Deno. Has that improved, or are there any concrete plans for it? Deno was really quite nice when I kicked the tires, but didn't seem quite ready for prime time web development with no crypto functions.

tracker1 6y ago
Not yet[1] likely to see WebCrypto first and/or something similar to Node's crypto library. You could probably get away with wasm build of a C/C++ or Rust library if you don't mind getting dirty. 1. https://github.com/denoland/deno/issues/1891 https://github.com/denoland/deno/issues/1891 edit: partial webcrypto/wasm option already available https://deno.land/x/god_crypto@v1.4.1 https://deno.land/x/god_crypto@v1.4.1

the_gipsy 6y ago

What's your plan for importing other typescript packages, natively? Last I remember is that every project/library has vastly different tsconfigs.

jbirer 6y ago

What are you wearing right now?