6 ms·

I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and t

I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?

eterm 3y ago
Deno being Node compatible is the "Embrace" in "Embrace, Extend, Extinguish".
- pavlov 3y ago
  Microsoft’s original successful application of this 3E strategy was predicated on them being the 300 kg gorilla in the market. Deno doesn’t seem to have that. When you’re the underdog, people don’t end up using your extensions without thinking.
  - eknkc 3y ago
    I could also work if Deno had to offer more than what Node does, while being compatible. People would start using Deno and then start using Deno specific things which are not compatible with Node. Long shot though.
    - endisneigh 3y ago
      yes. however Deno is the opposite of that. Typescript for example got adoption so fast because it was extremely easy to use typescript + javascript. Deno, however, inherently was against the node and npm sort of model. this makes sense in some sense since node does have a bunch of legacy cruft. however node is extremely popular and for adoption they need to support certain node features, and thus inherent the cruft. with each new adoption it makes less sense to use deno. I expect deno to convert all of their features to node modules and simply be an opinionated stack, similar to create-react-app vs. next.js. The path they're entertaining now isn't really tenable.
endisneigh 3y ago
Sad such a reasonable question is downvoted, lol. I agree with the sentiment. It's expected any development would want to have the highest reach, which means Node. If Deno supports node features, and node does not support deno clearly the logical conclusion is that features will be node-first, with deno expected to support it anyway. Thus leading to the question of why even bother with Deno? Deno does have some benefits, such as security model and speed, but those are not things that couldn't be added to Node. Once Node adds the security model why use Deno?
- forty 3y ago
  Nodejs is the de facto platform and ecosystem to write JS backend, and it seemed to me a bit weird that one would want to compete with it without being compatible with it which meant throwing away the very large ecosystem and existing code bases with no good reasons if you wanted to migrate. So congrats to them to have made it now, Deno can still compete on speed or tooling for example. Good Deno ideas will indeed probably make their way to Nodejs (or already did), and it's great, it makes Deno already useful for everyone even if it ends up not being used that much. About the security model: can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). I cannot see why a security team would want an isolation system that's different for a specific platform.
  - paulddraper 3y ago
    > can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). Those technologies are platform-specific and difficult to use. For example, provide the command line for running a Node.js program in Linux without file system access. In deno, it's deno run main.ts Or, to enable fs access: deno run --allow-read --allow-write main.ts --- That said, I agree that I'd rather rely on containers, VMs, etc.
    - mati365 3y ago
      Reinvent of unevil / pledge
deleted 3y ago
[deleted]
jrsj 3y ago
Well there’s more than just Node and Deno too. Cloudflare workers, etc. If you want portability across different worker runtimes and not just Deno, you’ll still want to avoid heavy Node API usage.
- paulddraper 3y ago
  Yay npm packages
derefr 3y ago
I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for some value of "work") in the other engines, so that their code can still be "portable" (i.e. at least not crash) despite calling the feature. Also, eventually, the other engines might introduce their own versions of the feature, with their own APIs, for the polyfill to fill over; and then even more eventually, those will get standardized. If there's a huge demand for the feature (think: XMLHTTPRequest), then other engines will rush to just clone the feature's API as-is, so that their engine won't be held back by the lack of it, or by the bad performance of a polyfill solution. But if there's next-to-no demand for doing what the feature does, such that you can predict that nobody will even bother to write a polyfill, let alone port the feature, and so the feature will languish in that one engine — then yes, people will intentionally avoid using that feature at that point. See e.g. most of the Microsoft ActiveX-based stuff you could do in Chakra (IE's long-dead JavaScript engine.)
- o1y32 3y ago
  Just want to point out one issue in your comment -- webkit, blink would be more suitable as examples for "browser runtimes". V8 and JavaScriptCore are JavaScript engines. In other words, the page here is more about platform APIs (or maybe "standard library") rather than JavaScript language features. V8 vs JavaScriptCore vs SpiderMonkey doesn't matter to most developers because they are mostly up-to-date with ECMAScript specs and the behavior is mostly consistently, while different browser engines have varying support for features.
  - derefr 3y ago
    Sure, but the sort of features I was referring to are more to do with things where one JS engine introduces a new pre-standardization language feature, like async/await. This used to happen a lot, before the standards got ahead of the implementation with E6. Unlike with browser-embedded JS engines, where "what native APIs are accessible from JS" is a relevant question†, in backend JS runtimes the answer to that question is always "all of them, because they're all just C FFI libraries, and these runtimes use the same C ABI, allowing interoperation with any such library." So for backend runtimes, it's only things to do with the JS engine itself — like language features — where the differences really matter. † And actually, browser JS engines could have gone this way as well, if NPAPI/PPAPI <object> had caught on. The "Java" in "JavaScript" was supposed to refer to using Java applets as ActiveX-like COM servers which would expose APIs to be scripted against! In other words: a common-standard for native FFI, just with sandboxing.
CuriouslyC 3y ago
I think this works for the same reason Typescript works. You can adopt with no changes, then slowly take advantage of advanced features.
TechBro8615 3y ago
Nah, Deno is just another runtime. Now we have the browser runtimes and multiple server runtimes. Not to mention we also have server runtimes like Cloudflare Workers that are "almost" Node in the sense that they run on V8, but without access to filesystem APIs. People will make sure to distribute their library so that it works on all of them. They might even use `deno compile` to bundle the library into a single file that can be consumed from any of the runtimes.
- tracker1 3y ago
  Note that even cloudflare workers is adding more node compatibility.
roqi 3y ago
> and thus Deno specific stuff will not be developed? Deno supports typescript out of the box. This alone greatly simplifies any deployment, and even if Deno did not offered anything else it would already take the lead in developer experience.
- tracker1 3y ago
  This is my take as well. Given the relative pain to configure ts projects in node. Especially with the harder lines between esm and cjs modules. It's kind of painful at times in the node space.

eterm 3y ago

Deno being Node compatible is the "Embrace" in "Embrace, Extend, Extinguish".

pavlov 3y ago
Microsoft’s original successful application of this 3E strategy was predicated on them being the 300 kg gorilla in the market. Deno doesn’t seem to have that. When you’re the underdog, people don’t end up using your extensions without thinking.
- eknkc 3y ago
  I could also work if Deno had to offer more than what Node does, while being compatible. People would start using Deno and then start using Deno specific things which are not compatible with Node. Long shot though.
  - endisneigh 3y ago
    yes. however Deno is the opposite of that. Typescript for example got adoption so fast because it was extremely easy to use typescript + javascript. Deno, however, inherently was against the node and npm sort of model. this makes sense in some sense since node does have a bunch of legacy cruft. however node is extremely popular and for adoption they need to support certain node features, and thus inherent the cruft. with each new adoption it makes less sense to use deno. I expect deno to convert all of their features to node modules and simply be an opinionated stack, similar to create-react-app vs. next.js. The path they're entertaining now isn't really tenable.

endisneigh 3y ago

Sad such a reasonable question is downvoted, lol. I agree with the sentiment. It's expected any development would want to have the highest reach, which means Node. If Deno supports node features, and node does not support deno clearly the logical conclusion is that features will be node-first, with deno expected to support it anyway. Thus leading to the question of why even bother with Deno? Deno does have some benefits, such as security model and speed, but those are not things that couldn't be added to Node. Once Node adds the security model why use Deno?

forty 3y ago
Nodejs is the de facto platform and ecosystem to write JS backend, and it seemed to me a bit weird that one would want to compete with it without being compatible with it which meant throwing away the very large ecosystem and existing code bases with no good reasons if you wanted to migrate. So congrats to them to have made it now, Deno can still compete on speed or tooling for example. Good Deno ideas will indeed probably make their way to Nodejs (or already did), and it's great, it makes Deno already useful for everyone even if it ends up not being used that much. About the security model: can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). I cannot see why a security team would want an isolation system that's different for a specific platform.
- paulddraper 3y ago
  > can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). Those technologies are platform-specific and difficult to use. For example, provide the command line for running a Node.js program in Linux without file system access. In deno, it's deno run main.ts Or, to enable fs access: deno run --allow-read --allow-write main.ts --- That said, I agree that I'd rather rely on containers, VMs, etc.
  - mati365 3y ago
    Reinvent of unevil / pledge

deleted 3y ago

[deleted]

jrsj 3y ago

Well there’s more than just Node and Deno too. Cloudflare workers, etc. If you want portability across different worker runtimes and not just Deno, you’ll still want to avoid heavy Node API usage.

paulddraper 3y ago
Yay npm packages

derefr 3y ago

I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for some value of "work") in the other engines, so that their code can still be "portable" (i.e. at least not crash) despite calling the feature. Also, eventually, the other engines might introduce their own versions of the feature, with their own APIs, for the polyfill to fill over; and then even more eventually, those will get standardized. If there's a huge demand for the feature (think: XMLHTTPRequest), then other engines will rush to just clone the feature's API as-is, so that their engine won't be held back by the lack of it, or by the bad performance of a polyfill solution. But if there's next-to-no demand for doing what the feature does, such that you can predict that nobody will even bother to write a polyfill, let alone port the feature, and so the feature will languish in that one engine — then yes, people will intentionally avoid using that feature at that point. See e.g. most of the Microsoft ActiveX-based stuff you could do in Chakra (IE's long-dead JavaScript engine.)

o1y32 3y ago
Just want to point out one issue in your comment -- webkit, blink would be more suitable as examples for "browser runtimes". V8 and JavaScriptCore are JavaScript engines. In other words, the page here is more about platform APIs (or maybe "standard library") rather than JavaScript language features. V8 vs JavaScriptCore vs SpiderMonkey doesn't matter to most developers because they are mostly up-to-date with ECMAScript specs and the behavior is mostly consistently, while different browser engines have varying support for features.
- derefr 3y ago
  Sure, but the sort of features I was referring to are more to do with things where one JS engine introduces a new pre-standardization language feature, like async/await. This used to happen a lot, before the standards got ahead of the implementation with E6. Unlike with browser-embedded JS engines, where "what native APIs are accessible from JS" is a relevant question†, in backend JS runtimes the answer to that question is always "all of them, because they're all just C FFI libraries, and these runtimes use the same C ABI, allowing interoperation with any such library." So for backend runtimes, it's only things to do with the JS engine itself — like language features — where the differences really matter. † And actually, browser JS engines could have gone this way as well, if NPAPI/PPAPI <object> had caught on. The "Java" in "JavaScript" was supposed to refer to using Java applets as ActiveX-like COM servers which would expose APIs to be scripted against! In other words: a common-standard for native FFI, just with sandboxing.

CuriouslyC 3y ago

I think this works for the same reason Typescript works. You can adopt with no changes, then slowly take advantage of advanced features.

TechBro8615 3y ago

Nah, Deno is just another runtime. Now we have the browser runtimes and multiple server runtimes. Not to mention we also have server runtimes like Cloudflare Workers that are "almost" Node in the sense that they run on V8, but without access to filesystem APIs. People will make sure to distribute their library so that it works on all of them. They might even use `deno compile` to bundle the library into a single file that can be consumed from any of the runtimes.

tracker1 3y ago
Note that even cloudflare workers is adding more node compatibility.

roqi 3y ago

> and thus Deno specific stuff will not be developed? Deno supports typescript out of the box. This alone greatly simplifies any deployment, and even if Deno did not offered anything else it would already take the lead in developer experience.

tracker1 3y ago
This is my take as well. Given the relative pain to configure ts projects in node. Especially with the harder lines between esm and cjs modules. It's kind of painful at times in the node space.