5 ms·

Few things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today

Few things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doubt they are as mature. 2. Deno's security model overly hyped at least i see it this way. In last few version of NodeJS, many security flaws have been addressed, see their changelog if you dont believe me. But most importantly, security flaws with native JS is handled by V8 which is common to both NodeJS and Deno. On top of that, most of the libraries and frameworks in NodeJS during their various releases sorted out many security issues in their code. If someone is still doubtful they can use eslint-plugins for sanity and security checks in their JS files. Adopting Typescript also helps if you cant live without types. 3. Learning curve to adopt new SDK for Socket API, File API, System call API etc. I don't think NodeJS falls short significantly anywhere, in fact it provides more and those APIs have been relatively more battle tested over the years. 4. Irrespective of using NodeJS or Deno, following a BDD/TDD practices to ensure sound test coverage of your business use logic still remain the most promising tool to make, break and refactor your codebase.

nitsky 6y ago
Regarding point 3, Deno's APIs use language features that were unavailable when node was written, including promises and async iterators. That is a big improvement IMO.
- truth_seeker 6y ago
  You can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities. https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... It was introduced in NodeJS 8.x release. The latest LTS version is 12.x
  - nitsky 6y ago
    Promisifying makes the node APIs more convenient, but you still do not have the ability to provide back-pressure. See the link below: https://deno.land/v1#promises-all-the-way-down https://deno.land/v1#promises-all-the-way-down
    - truth_seeker 6y ago
      There are definitely few things which are done in different way in Deno as part of re-design. But that does not mean NodeJS does not take care of it or at least provide the some API to tackle that issue. In this case, Stream interface API in NodeJS are the solution to the problem. They help you build layer over native EventEmitter interface or rather strictly speaking they help extend it. This links might be helpful for you. Backpressuring in Streams - https://nodejs.org/es/docs/guides/backpressuring-in-streams/ https://nodejs.org/es/docs/guides/backpressuring-in-streams/ Official Docs on Stream API - https://github.com/nodejs/node/blob/master/doc/api/stream.md https://github.com/nodejs/node/blob/master/doc/api/stream.md Note that HTTP server in NodeJS already implements it.
thosakwe 6y ago
Solely addressing #1 here, and this may come off harsh, but I think it's ridiculous to expect Deno to match the library ecosystem of Node on day 1. That's just literally impossible, but whenever a new language or runtime is released, it manages to become the most prominent question/concern. It also is something of a moot point anyways, because people pushing something into production already are probably not using something so new. Early adopters don't care about how mature the ecosystem is; part of the appeal of being an early adopter is helping to build that ecosystem...
- tosserup478 6y ago
  Well, you should scratch language there. kotlin did manage to start with the huge ecosystem of Java without hassle
mcintyre1994 6y ago
There's no way it's going to match everything, but regarding number 1 - it does look like you can drop in some node modules. A small example, but one that surprised me - React works. So you can do React with SSR with nothing else, eg. this demo is a pretty refreshing one to see how few moving pieces there are. https://github.com/brianleroux/arc-example-deno-ssr https://github.com/brianleroux/arc-example-deno-ssr . It's just imported as `import { React, ReactDOM } from 'https://unpkg.com/es-react'` https://unpkg.com/es-react'`
- truth_seeker 6y ago
  By no means i am demotivating anyone. I have just enumerated the minimum possible evaluation criteria and current state of development. This is what i often do at my workplace as an Architect. If someone is eager to try out new possibilities in Deno and their application use cases intersect well with what Deno has to offer, then by all means it's a good decision.

nitsky 6y ago

Regarding point 3, Deno's APIs use language features that were unavailable when node was written, including promises and async iterators. That is a big improvement IMO.

truth_seeker 6y ago
You can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities. https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... It was introduced in NodeJS 8.x release. The latest LTS version is 12.x
- nitsky 6y ago
  Promisifying makes the node APIs more convenient, but you still do not have the ability to provide back-pressure. See the link below: https://deno.land/v1#promises-all-the-way-down https://deno.land/v1#promises-all-the-way-down
  - truth_seeker 6y ago
    There are definitely few things which are done in different way in Deno as part of re-design. But that does not mean NodeJS does not take care of it or at least provide the some API to tackle that issue. In this case, Stream interface API in NodeJS are the solution to the problem. They help you build layer over native EventEmitter interface or rather strictly speaking they help extend it. This links might be helpful for you. Backpressuring in Streams - https://nodejs.org/es/docs/guides/backpressuring-in-streams/ https://nodejs.org/es/docs/guides/backpressuring-in-streams/ Official Docs on Stream API - https://github.com/nodejs/node/blob/master/doc/api/stream.md https://github.com/nodejs/node/blob/master/doc/api/stream.md Note that HTTP server in NodeJS already implements it.

thosakwe 6y ago

Solely addressing #1 here, and this may come off harsh, but I think it's ridiculous to expect Deno to match the library ecosystem of Node on day 1. That's just literally impossible, but whenever a new language or runtime is released, it manages to become the most prominent question/concern. It also is something of a moot point anyways, because people pushing something into production already are probably not using something so new. Early adopters don't care about how mature the ecosystem is; part of the appeal of being an early adopter is helping to build that ecosystem...

tosserup478 6y ago
Well, you should scratch language there. kotlin did manage to start with the huge ecosystem of Java without hassle

mcintyre1994 6y ago

There's no way it's going to match everything, but regarding number 1 - it does look like you can drop in some node modules. A small example, but one that surprised me - React works. So you can do React with SSR with nothing else, eg. this demo is a pretty refreshing one to see how few moving pieces there are. https://github.com/brianleroux/arc-example-deno-ssr https://github.com/brianleroux/arc-example-deno-ssr . It's just imported as `import { React, ReactDOM } from 'https://unpkg.com/es-react'` https://unpkg.com/es-react'`

truth_seeker 6y ago
By no means i am demotivating anyone. I have just enumerated the minimum possible evaluation criteria and current state of development. This is what i often do at my workplace as an Architect. If someone is eager to try out new possibilities in Deno and their application use cases intersect well with what Deno has to offer, then by all means it's a good decision.