5 ms·

Thank you for explaining like I'm five, and not assuming prior domain knowledge! You've greatly increased my understanding of the nature of Deno and NodeJS and

Thank you for explaining like I'm five, and not assuming prior domain knowledge! You've greatly increased my understanding of the nature of Deno and NodeJS and how they relate to each other, I'm starting to get it. What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else? But perhaps that ship has sailed, and the answer now is just inertia, people use JavaScript because people are already using JavaScript :P

flyingchipmann 6y ago
Obvious reasons but not restricted to: 1. performance: v8 is incredibly fast. 2. convenience: many ppl are already pretty familiar with javascript and node/deno gave them the ability to use it generically outside the browser
doteka 6y ago
Because Typescript is one of the best languages we have today and has major advantages over all others mentioned? I write (or have written, in the case of Go) all 4 professionally. - a vast ecosystem all based on async IO, sidestepping the colored function problem, as opposed to the clusterfuck that is Python’s asyncio ecosystem - a powerful and expressive structural typing system that allows you to make illegal states unrepresentable in many cases, similar to Rust, as opposed to the language of interface{} and if err != nil - I feel silly comparing it to Rust because the Venn diagram of what problems these 2 languages are appropriate for looks like 2 disjoint circles to me. Yes, technically you could write your backends in Rust, and your competitor using Node will launch their MVP 2 years before you do.
didibus 6y ago
> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else? I would say familiarity is a big one. Lots of people now learn JavaScript first, and once you know it well, having to re-learn a whole other language might seem like a big hurdle that if you can avoid seems like a good proposition. Another one is this new concept of "full stack". While most JS code in browser and in server won't work as is, there's still a lot of overlap. So you can have subsets of code that you can copy/paste from your front-end into your backend and vice versa. This also means that as a dev, if you want to do backend and frontend work, you only need to learn one language, that's 50% less effort on your part than having to learn two languages :p Something else that kind of happened as a lucky accident is that JavaScript was designed for event driven programming mostly, due to it being used as a language to handle user events on webpages for interactivity. Now it turns out that the problem of managing interactive user interfaces is highly concurrent in nature. At the same time, it happened that most backend code needed to scale horizontally, which meant that it too needed to become highly concurrent. This was the innovation brought by NodeJS to the backend. It was one of the first run-time for backend that was designed exclusively in an event driven model, which actually allowed it to scale quite well for non CPU intensive workloads. In that sense NodeJS was a pioneer on the back end side as well, and other runtimes are just catching up. Finally, writing an optimized runtime for any language is a huge endeavour. It requires lots of dev work and effort, which is quite expensive. Since web browsers make a ton of money and are backed by the richest companies around, and they care a lot about the performance of JavaScript in their browsers, there's actually an immense amount of investment made to the JS interpreter and virtual machines to have it be as efficient and optimized as can be. In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. There's not many things that can rival that, you've got Go, JDK, .Net, GCC, and the Rust compiler maybe. The former because they've also had ton of money poured into them, and the latter because its entire language design and everything targets performance. Also you've got OCaml, Haskell, CommonLisp and Scheme runtimes of yore that might rival it due to how long they've had dedicated researchers and volunteers contribute. In any case, it means JS VMs are quite competitive performance wise.
- bitwize 6y ago
  > In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. Except for the various Lisp flavors that have really high speed implementations.
e12e 6y ago
> What I still don't fully understand is why people want to write non-webpage software in JavaScript Many good sibling answers already - but another thing to note - is that if you want a modern (js) front-end and optional server side rendering (for faster initial load/display and/or to present something nice to search engine crawlers) - you'll probably end up having to execute js on the server side too. Also, there's the hope of being able to re-use code for business logic, like validating data - you can (should) validate client side for better ux (quick feedback on misding/wrong data) - but since you cannot trust the client you have to validate server side. Obviously it seems attractive to write that validation code in one place, always having it in sync between client and server.
slightwinder 6y ago
> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. There are multiple reasons, but it mainly comes down to 1) JavaScript is simple and widely used. And as many people are using it, those many people often also have the wish to use it outside the web for other things. 2) Webpage-Software has evolved to Application-Software in the last decade, and nowadays you can create proper interfaces with javascript&css&html which can compete with native desktop-software in terms of ability and somewhat performance. 3) You have one sourcecode for all devices. You only need to write it once, and use it everywhere with a little bit of tweaking. Which is cheaper and faster than writing separate software for every platform and device.

flyingchipmann 6y ago

Obvious reasons but not restricted to: 1. performance: v8 is incredibly fast. 2. convenience: many ppl are already pretty familiar with javascript and node/deno gave them the ability to use it generically outside the browser

doteka 6y ago

Because Typescript is one of the best languages we have today and has major advantages over all others mentioned? I write (or have written, in the case of Go) all 4 professionally. - a vast ecosystem all based on async IO, sidestepping the colored function problem, as opposed to the clusterfuck that is Python’s asyncio ecosystem - a powerful and expressive structural typing system that allows you to make illegal states unrepresentable in many cases, similar to Rust, as opposed to the language of interface{} and if err != nil - I feel silly comparing it to Rust because the Venn diagram of what problems these 2 languages are appropriate for looks like 2 disjoint circles to me. Yes, technically you could write your backends in Rust, and your competitor using Node will launch their MVP 2 years before you do.

didibus 6y ago

> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else? I would say familiarity is a big one. Lots of people now learn JavaScript first, and once you know it well, having to re-learn a whole other language might seem like a big hurdle that if you can avoid seems like a good proposition. Another one is this new concept of "full stack". While most JS code in browser and in server won't work as is, there's still a lot of overlap. So you can have subsets of code that you can copy/paste from your front-end into your backend and vice versa. This also means that as a dev, if you want to do backend and frontend work, you only need to learn one language, that's 50% less effort on your part than having to learn two languages :p Something else that kind of happened as a lucky accident is that JavaScript was designed for event driven programming mostly, due to it being used as a language to handle user events on webpages for interactivity. Now it turns out that the problem of managing interactive user interfaces is highly concurrent in nature. At the same time, it happened that most backend code needed to scale horizontally, which meant that it too needed to become highly concurrent. This was the innovation brought by NodeJS to the backend. It was one of the first run-time for backend that was designed exclusively in an event driven model, which actually allowed it to scale quite well for non CPU intensive workloads. In that sense NodeJS was a pioneer on the back end side as well, and other runtimes are just catching up. Finally, writing an optimized runtime for any language is a huge endeavour. It requires lots of dev work and effort, which is quite expensive. Since web browsers make a ton of money and are backed by the richest companies around, and they care a lot about the performance of JavaScript in their browsers, there's actually an immense amount of investment made to the JS interpreter and virtual machines to have it be as efficient and optimized as can be. In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. There's not many things that can rival that, you've got Go, JDK, .Net, GCC, and the Rust compiler maybe. The former because they've also had ton of money poured into them, and the latter because its entire language design and everything targets performance. Also you've got OCaml, Haskell, CommonLisp and Scheme runtimes of yore that might rival it due to how long they've had dedicated researchers and volunteers contribute. In any case, it means JS VMs are quite competitive performance wise.

bitwize 6y ago
> In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. Except for the various Lisp flavors that have really high speed implementations.

e12e 6y ago

> What I still don't fully understand is why people want to write non-webpage software in JavaScript Many good sibling answers already - but another thing to note - is that if you want a modern (js) front-end and optional server side rendering (for faster initial load/display and/or to present something nice to search engine crawlers) - you'll probably end up having to execute js on the server side too. Also, there's the hope of being able to re-use code for business logic, like validating data - you can (should) validate client side for better ux (quick feedback on misding/wrong data) - but since you cannot trust the client you have to validate server side. Obviously it seems attractive to write that validation code in one place, always having it in sync between client and server.

slightwinder 6y ago

> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. There are multiple reasons, but it mainly comes down to 1) JavaScript is simple and widely used. And as many people are using it, those many people often also have the wish to use it outside the web for other things. 2) Webpage-Software has evolved to Application-Software in the last decade, and nowadays you can create proper interfaces with javascript&css&html which can compete with native desktop-software in terms of ability and somewhat performance. 3) You have one sourcecode for all devices. You only need to write it once, and use it everywhere with a little bit of tweaking. Which is cheaper and faster than writing separate software for every platform and device.