4 ms·

If you don't use the node compatibility do you even notice or care one bit about it? It doesn't hurt a pure deno project at all.

lolinder 3y ago
If Deno has no Node compatibility then you know that no Deno library pulls Node modules in with it, because it's impossible. The more seamless node interop becomes, the harder it will be to sift the Pure Organic Deno libraries from the NPM-infused Deno libraries. So, on the contrary: Node becoming embraced by the wider ecosystem absolutely hurts pure Deno projects because they'll rapidly become perceived as a fundamentalist minority that doesn't need to be catered to, where the original idea was that all projects would be pure.
- qbasic_forever 3y ago
  I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. You have a very bizarre argument that I don't follow. I don't care about the "purity" of the project, I care about getting shit done and deno is helping greatly there.
  - toastercat 3y ago
    > I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. It's not that simple if the project you are importing uses Node-specific APIs. By the way, this is an area that can really confuse newbies.
  - no_wizard 3y ago
    then you're stuck with a CDN you don't control. The runtime (Deno) being able to work directly with most packages on npm is a huge win because I don't have to trust a 3rd party for this anymore, and that to me is a big win.
    - qbasic_forever 3y ago
      Agreed, I'm just refuting the reply above that deno recently besmirched some bizarre purity by adding friendly node NPM support. From the very beginning of deno you could import any JS code, including simple stuff from npm that didn't rely on then unsupported node APIs.
- JamesSwift 3y ago
  Seems like it could easily just be a compiler flag to 'only allow pure deno' and then fail/warn if a dependency pulls in npm stuff.
  - toastercat 3y ago
    I think a flag like that shouldn't have to exist. It's complicating and bloating the runtime more just to gain more adoption, not to make Deno actually better.
    - rhaway84773 3y ago
      I think not wanting to pull packages in from the largest package ecosystem in JS land is a fairly marginal need which should only be catered to through a setting, if at all. You can always not add NPM packages if that’s something that bothers you, and there are probably fairly simple ways to add a lint step that ensures you’re doing that by simply scanning your package.json (which makes me think…can’t you simply not add a package.json? The original direct URL library references will be around anyways).
      - WorldMaker 3y ago
        You just have to also lint your URL imports for "npm:" URLs. That's an easy enough lint. (Though slightly more complicated if you also decide to block in your lint rule other common npm-based CDNs like unpkg/esm.sh/others.)

lolinder 3y ago

If Deno has no Node compatibility then you know that no Deno library pulls Node modules in with it, because it's impossible. The more seamless node interop becomes, the harder it will be to sift the Pure Organic Deno libraries from the NPM-infused Deno libraries. So, on the contrary: Node becoming embraced by the wider ecosystem absolutely hurts pure Deno projects because they'll rapidly become perceived as a fundamentalist minority that doesn't need to be catered to, where the original idea was that all projects would be pure.

qbasic_forever 3y ago
I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. You have a very bizarre argument that I don't follow. I don't care about the "purity" of the project, I care about getting shit done and deno is helping greatly there.
- toastercat 3y ago
  > I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. It's not that simple if the project you are importing uses Node-specific APIs. By the way, this is an area that can really confuse newbies.
- no_wizard 3y ago
  then you're stuck with a CDN you don't control. The runtime (Deno) being able to work directly with most packages on npm is a huge win because I don't have to trust a 3rd party for this anymore, and that to me is a big win.
  - qbasic_forever 3y ago
    Agreed, I'm just refuting the reply above that deno recently besmirched some bizarre purity by adding friendly node NPM support. From the very beginning of deno you could import any JS code, including simple stuff from npm that didn't rely on then unsupported node APIs.
JamesSwift 3y ago
Seems like it could easily just be a compiler flag to 'only allow pure deno' and then fail/warn if a dependency pulls in npm stuff.
- toastercat 3y ago
  I think a flag like that shouldn't have to exist. It's complicating and bloating the runtime more just to gain more adoption, not to make Deno actually better.
  - rhaway84773 3y ago
    I think not wanting to pull packages in from the largest package ecosystem in JS land is a fairly marginal need which should only be catered to through a setting, if at all. You can always not add NPM packages if that’s something that bothers you, and there are probably fairly simple ways to add a lint step that ensures you’re doing that by simply scanning your package.json (which makes me think…can’t you simply not add a package.json? The original direct URL library references will be around anyways).
    - WorldMaker 3y ago
      You just have to also lint your URL imports for "npm:" URLs. That's an easy enough lint. (Though slightly more complicated if you also decide to block in your lint rule other common npm-based CDNs like unpkg/esm.sh/others.)