4 ms·

If you hadn't realized, JS is a scripting language, which does not have an official runtime. What that means is... How is JS code executed? You need some othe

If you hadn't realized, JS is a scripting language, which does not have an official runtime. What that means is... How is JS code executed? You need some other program to interpret (and possibly JIT compile) the JavaScript and actually execute it. Normally that "other program" is a web browser like Chrome, FireFox, Safari, Opera, etc. But those programs run JavaScript in a restricted way. That is, they only execute JavaScript attached to a web page that they loaded and within the context of that page, and they limit what the JavaScript can do to the operating system. Like can it delete files on your disk? Can it listen to an open port? Etc. Also, those programs don't let you run JavaScript conveniently outside the context of a webpage. You can't just do at the command line: `chrome myscript.js` Thus if you wanted to use JavaScript to write command line applications or desktop applications, using a web browser wouldn't work. So we need another program that lets you run JavaScript from the command line, or as an executable, and we need that program to provide more facilities to the JavaScript code which allows it to do more things to the OS, such as deleting files from the disk, listening to a port, connecting to arbitrary remote servers, etc. The first such program to appear was NodeJS. And some people don't like it. They don't like the way it runs JavaScript and the way it has exposed to JavaScript those additional OS facilities. Thus they decided to create another one called Deno. Most languages have one defacto run-time, for example for Python it's CPython, for Ruby it is MRI, for Java it is OpenJDK, etc. And if they have alternative ones, like Ruby also has JRuby for example. They normally copy the same language APIs, so that code for one works on the other. In the case of Deno this is not the case. Deno decided that the NodeJS exposed JavaScript APIs arn't great, so it has a different set of language APIs. That means JavaScript code written for NodeJS will not work for Deno and vice versa. It's really rare to see such a split in mainstream established languages, because the cost of breaking compatibility with established "in-production" code is normally too high. For example, Microsoft has build .NET core, as a new run-time for C#, but it tried really hard to provide all of the old .NET framework APIs, yet not all of them, so it did break se backwards compatibility. I believe Deno will break much more. I've only seen this happen in the past for less popular languages, like Smalltalk has a bunch of slightly incompatible runtimes: Squeak, VisualWorks, Pharo, Cuis, etc. And when that happens, sometimes people even consider it a whole new language, like a dialect. So in some ways, you could almost consider NodeJS and Deno to be dialects of JavaScript, since their code isn't compatible and their APIs and some of their features will differ. Similarly, their code will not always run in a browser either without rewrite, because again, the capabilities and APIs differ. Hope this helps, I know it's kind of complicated, but at the same time it's simple. You need a runtime to run JavaScript. Each runtime can expose different APIs to the JavaScript to use, and each runtime can choose to support custom extensions of JavaScript or choose to not support certain features of JavaScript, etc. Deno and NodeJS are two such runtimes for JavaScript that are both making different choices.

skyfaller 6y ago
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.

skyfaller 6y ago

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.