4 ms·

Can someone explain to me what problem that Deno and Node are trying to solve? Is JavaScript really such an amazing language that we need to use it for backend

Can someone explain to me what problem that Deno and Node are trying to solve? Is JavaScript really such an amazing language that we need to use it for backend applications now? What niche is it filling that is unfilled by other, more sanely designed programming languages? I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with).

chrisco255 6y ago
Node.js has been used in production for over a decade. Some of the most popular applications of the past decade have been built on Node and in 2020, JavaScript is the most popular programming language.
franciscop 6y ago
This seems like trolling more than a genuine question, but I'll answer in case it is genuine. It makes it easier for fullstack developers since it's a single language both in the front-end and back-end. You only need to learn once how `JSON.parse()`, `atob`, classes/prototypes, etc. work, and not worry about language inconsistencies making errors. It is decently efficient (not the best, not the worst), fairly readable (I'd say on the upper side). The three main disadvantages IMHO are: - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages - Node.js standard library is optimizing for flexibility instead of conciseness or completeness, so there's quite a bit of manual gruntwork involved (not the worst of those mentioned though). - Right now the ecosystem is in a major migration from `require()` to `import`. The last large migration like this was from Callbacks to Promises, and IMHO it went very well. As someone who is very comfortable with Javascript, and was comfortable with PHP and Python back in the day, I would not trade Node.js for any of those. I am thinking most of the time about what I want to achieve in a coherent way, and not fumbling with pointers.
- mekster 6y ago
  > - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages Grasping isn't the hard part, it's just about placing callback functions on executed functions that allows callbacks. What's so bad is that it is async by default and now you need million "await" and "async" keywords all over the place. I wish it would be sync by default and for those rare cases where you really want it async, you would add a keyword.
  - franciscop 6y ago
    I mean 4 of the very common Node.js operations are async by nature: database calls, file access, external API calls and crypto.
    - dragonwriter 6y ago
      They aren't async by nature, just time consuming. Async is a useful way of dealing with time consuming operations in some situations, but blocking calls also a work (and make more sense for some workloads.)
Rapzid 6y ago
Reasons for node: * Testing/running code that will run on a browser javascript vm outside of the browser * Developer familiarity * Reduced context switching * Reasonably good asynchronous performance given the above * TypeScript, given the above * Shared backend/frontend code(SSR, etc etc) Interestingly I wouldn't really want to reach for any of your alternatives as a general substitute for NodeJS/TypeScript.. C# or F# perhaps.
jrs95 6y ago
It's now the most popular programming language by a decent margin, there are a lot of libraries available for it, and it lacks some of the performance limitations that affect other dynamic languages. Anyone that does frontend dev knows JavaScript, its about as close to a universal language as you can get. Personally theres about a dozen other things I'd rather use but from a pragmatic perspective it makes sense. It's easy and it gets the job done relatively quickly.
mekster 6y ago
The engine V8 is developed for Chrome, so you can say it will be stable and actively developed for a very long while and there are plenty of resources online for the language itself. And there's TypeScript if you think JS isn't "sane".
dragonwriter 6y ago
> Can someone explain to me what problem that Deno and Node are trying to solve? Deno and Node aren't solving the same exact same set of problems. > Is JavaScript really such an amazing language that we need to use it for backend applications now? Yes, for select values of “we”; productivity with programming languages being both subjective and path-dependent. But Node and Deno aren't so much about JS as a developer language as JS as a multi-language runtime, similar to the JVM. Just as one might use Scala, Kotlin, Clojure, Ruby, or other languages on the JVM, there are a large number of languages one can run on a JS engine. > I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with). Because your subjective idea of sanity isn't universal; and because there are substantial productivity advantages in sharing programming languages between front and back end, especially when you've got the same team doing both.

chrisco255 6y ago

Node.js has been used in production for over a decade. Some of the most popular applications of the past decade have been built on Node and in 2020, JavaScript is the most popular programming language.

franciscop 6y ago

This seems like trolling more than a genuine question, but I'll answer in case it is genuine. It makes it easier for fullstack developers since it's a single language both in the front-end and back-end. You only need to learn once how `JSON.parse()`, `atob`, classes/prototypes, etc. work, and not worry about language inconsistencies making errors. It is decently efficient (not the best, not the worst), fairly readable (I'd say on the upper side). The three main disadvantages IMHO are: - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages - Node.js standard library is optimizing for flexibility instead of conciseness or completeness, so there's quite a bit of manual gruntwork involved (not the worst of those mentioned though). - Right now the ecosystem is in a major migration from `require()` to `import`. The last large migration like this was from Callbacks to Promises, and IMHO it went very well. As someone who is very comfortable with Javascript, and was comfortable with PHP and Python back in the day, I would not trade Node.js for any of those. I am thinking most of the time about what I want to achieve in a coherent way, and not fumbling with pointers.

mekster 6y ago
> - Its async nature is more difficult to grasp for beginners compared to one thread/request and then linear-ish work of some other languages Grasping isn't the hard part, it's just about placing callback functions on executed functions that allows callbacks. What's so bad is that it is async by default and now you need million "await" and "async" keywords all over the place. I wish it would be sync by default and for those rare cases where you really want it async, you would add a keyword.
- franciscop 6y ago
  I mean 4 of the very common Node.js operations are async by nature: database calls, file access, external API calls and crypto.
  - dragonwriter 6y ago
    They aren't async by nature, just time consuming. Async is a useful way of dealing with time consuming operations in some situations, but blocking calls also a work (and make more sense for some workloads.)

Rapzid 6y ago

Reasons for node: * Testing/running code that will run on a browser javascript vm outside of the browser * Developer familiarity * Reduced context switching * Reasonably good asynchronous performance given the above * TypeScript, given the above * Shared backend/frontend code(SSR, etc etc) Interestingly I wouldn't really want to reach for any of your alternatives as a general substitute for NodeJS/TypeScript.. C# or F# perhaps.

jrs95 6y ago

It's now the most popular programming language by a decent margin, there are a lot of libraries available for it, and it lacks some of the performance limitations that affect other dynamic languages. Anyone that does frontend dev knows JavaScript, its about as close to a universal language as you can get. Personally theres about a dozen other things I'd rather use but from a pragmatic perspective it makes sense. It's easy and it gets the job done relatively quickly.

mekster 6y ago

The engine V8 is developed for Chrome, so you can say it will be stable and actively developed for a very long while and there are plenty of resources online for the language itself. And there's TypeScript if you think JS isn't "sane".

dragonwriter 6y ago

> Can someone explain to me what problem that Deno and Node are trying to solve? Deno and Node aren't solving the same exact same set of problems. > Is JavaScript really such an amazing language that we need to use it for backend applications now? Yes, for select values of “we”; productivity with programming languages being both subjective and path-dependent. But Node and Deno aren't so much about JS as a developer language as JS as a multi-language runtime, similar to the JVM. Just as one might use Scala, Kotlin, Clojure, Ruby, or other languages on the JVM, there are a large number of languages one can run on a JS engine. > I'm not trying to be obtuse or anything, I'm just really curious as to why anyone would use Deno (or Node for that matter) for a project when I can think of at least 4 alternatives that are more sane (Go, Python, Rust, Java, and many more out there, just that these are the ones I'm most comfortable with). Because your subjective idea of sanity isn't universal; and because there are substantial productivity advantages in sharing programming languages between front and back end, especially when you've got the same team doing both.