3 ms·

For starters Deno is much, much faster in both installation and runtime. I am not sure if I'll have the chance to exploit other features it has (besides the bu

• satvikpendem 3y ago
  How is it faster in runtime? Isn't it all V8 at the end?
  • RussianCow 3y ago
    It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.
    • jokethrowaway 3y ago
      Same with bun, it looks like node is leaving some performance on the table (maybe for backward compatibility or maybe because nobody bothered to improve it)
      • kibibu 3y ago
        Bun doesn't use V8, so there are other performance differences there
        • factormeta 3y ago
          It is fair to note, that JavascriptCore outperforms V8 already. However, it is in Zig. And Deno is in Rust.
    • satvikpendem 3y ago
      What does that mean, though? Does Deno create an HTTP server in Rust directly?
      • DanielHB 3y ago
        A ton of NodeJS modules are not part of V8 at all, like "fs" or "path" because those don't really make sense in a browser context. Basically everything that is not a W3C standard is probably not implemented in V8. Like, for example, I recently found out that there are 3 separate ReadbleStream objects in NodeJS, one from "stream" (older one used in Request), one from "stream/web" (W3C standard, used by global.fetch()) and another one I forgot where it comes from. It doesn't help that two of them have the same name and you run into errors like "ReadableStream is not of type ReadableStream". I assume the one from "stream/web" directly calls into V8 APIs because since it is a standard it would be implemented in V8 (it is used in the browser's window.fetch() after all). While the one from "stream" is built and maintained by NodeJS Foundation. It is not really reasonable to expect the NodeJS Foundation to have enough resources to optimise all this modules to the max. And the W3C doesn't seem interested in building standards for server-side only things.
        • OscarDC 3y ago
          To add to this, a lot of those "W3C API" (most?) (to which I'll also add WHATWG API, like HTML5 - or fetch) have actually no relation to ECMAScript and thus aren't generally in v8 because they are not JavaScript. Those API could be thought as from the "environment" in which JavaScript run. For example we often call web-only APIs "DOM API": `fetch`, `xmlHttpRequest` and so on. Node.js also has its own environment. For example both `setTimeout` and `setInterval`, though present in both web and node.js, are implemented differently by browsers and node.js (it's just that node.js decided to go with roughly the same API - see below for code examples for both). Taking requests as examples there are both declared in blink, the rendering engine and not v8 again because they aren't JS: - fetch (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fetch/ https://source.chromium.org/chromium/chromium/src/+/main:thi...) - XMLHttpRequest (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/xmlhttprequest/ https://source.chromium.org/chromium/chromium/src/+/main:thi...) For the fun of looking even more at some code of reputable projects: for setTimeout / setInterval, I would guess they are declared here in blink: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/scheduler/dom_timer.cc https://source.chromium.org/chromium/chromium/src/+/main:thi... And maybe here for Node.js: https://github.com/nodejs/node/blob/8a41d9b636be86350cd32847c3f89d327c4f6ff7/lib/timers.js https://github.com/nodejs/node/blob/8a41d9b636be86350cd32847... To note that "filesystem" API also exist in web world: https://fs.spec.whatwg.org https://fs.spec.whatwg.org Again, this API is completely different than in Node.JS