5 ms·

I mean... not really? The goals of Deno and Node are different, the architecture is different. Adding a compatibility layer helps Deno grow while maintaining

I mean... not really? The goals of Deno and Node are different, the architecture is different. Adding a compatibility layer helps Deno grow while maintaining its original goals. I doubt this adds much complexity if done properly...

joshmanders 4y ago
Clearly you've never seen the at least 2 talks that Ryan Dahl has given about how he viewed package.json and npm as the two biggest blunders of Node's life and he was going to correct that in Deno. And here we are.
- MrOwnPut 4y ago
  I have, but you glossed over my point. What's wrong with a compatibility layer with npm if it's implemented properly? His views on package.json and implementing a compatibility layer to help others transition from node are not mutually exclusive. The support for node is pretty simple. Using NPM packages is straight forward. Reading a package.json file and using those mappings isn't complex either. Deno does not use node_modules in any of those instances...
  - joshmanders 4y ago
    His point was that the mere ability was the issue, not some implementation. This is why Deno has gone so long without a true package manager. The problem here is now they're fighting for adoption so they're going against their original values because they know what they wanted isn't what the broader community wants.
    - MrOwnPut 4y ago
      > His point was that the mere ability was the issue Can you elaborate? > so they're going against their original values because they know what they wanted isn't what the broader community wants. No, they are still sticking to everything, but added support for the existing ecosystem. Yes they are adding this to combat the network effect that node has, but it doesn't really go against anything. You simply prefix npm in front of npm imports. Now you could use a package.json file if you already have one, but you don't have to.
      - tsimionescu 4y ago
        No. They are adding "deno:package@version" native imports, and they are adding a deno.json file to specify them. They are adding dependency resolution logic for these native deno packages to deno itself. The fact that all this interoperates with NPM as well is just an added bonus. But even if NPM died tomorrow, deno would go on having a package system, because they have realized how important it actually is (to fix things like what they call the "duplicate dependency problem").
        MrOwnPut 4y ago
        Yes and that is nice, it'll allow future import map support, like in the browser, which is inline with Deno's goal of using browser APIs instead of proprietary ones. But the package.json format part is a backwards compatibility feature. The preferred import maps will be the ideal solution (if you do need dependency management). None of that really goes against direct imports, which work well for single file scripts, workers, etc. Choose what fits.
  - hbn 4y ago
    The blog post didn't make it sound like this was implemented just for the sake of backwards compatibility, it sounds more like an admission that Deno's take on package management isn't a superior solution to how Node did it before.
    - MrOwnPut 4y ago
      Could you point out a few things in the blog that made it sound that way to you? It states many times it was added for backwards compatibility. Even at the bottom of TFA they annotate the ideal solution (which will be implemented soon) is to use import maps instead of package.json, the same format the browser uses, which is in line with Deno's main goals.
      - tsimionescu 4y ago
        You're ignoring the fact that, originally, deno wanted to eschew the concept of an import map entirely. They weren't against the format of package.json itself, or even against the fact that it's not a web standard. They were against the idea of having to specify imports sepeartely from your code, and against the idea of bundling multiple files into a concept of a module. Fast forward a few years, and they are now adding these two things natively to deno, just as the web ecosystem did. Turns out, Node was right to have modules and an import file all along, and at worst there were some minor implementation quibbles to argue about.
        MrOwnPut 4y ago
        Personally I don't really care about the faux drama. I'm glad I can use direct url imports in simple Deno scripts. I also see the need for import maps for larger projects. I do think node_modules is an abomination and glad I don't have to deal with them anymore. I prefer writing everything that works in Deno and the browser, not Node specific APIs. I like the tech, I don't really care about the drama, and I doubt the Ryan does either lol.
        tsimionescu 4y ago
- faitswulff 4y ago
  From what I remember, Dahl considered node_modules one of the big blunders, which afaict they have avoided with Deno.
- hombre_fatal 4y ago
  Ryan Dahl's talk reminds me of the time I came back to a forum I created and then neglected after being distracted by university for four years. The forum had taken off while I was MIA. In spite of me being MIA. And while I could write a manifesto about how the forum had gone in a direction I didn't necessarily want, I had to admit that my plans for the forum weren't better nor more correct than the plans that emerged organically from the community over the years. When you create something with a community and ecosystem, it's easy to see the success of the ecosystem and the downstream success of the people within it as your success when in reality you are more like an early collaborator who set the stage for others to join in and take it from there. A good example of this in my case was the hubris that, because I created that one big forum, I could create more successful forums. I never hit gold again. I realized I wasn't some master forum creator, just someone who started something at the right time and the right place with just enough TLC to attract other builders, and that I didn't have some divine insight into how to start a successful forum. Oof.
  - joshmanders 4y ago
    You hit the nail on the head here. This is exactly what's going on.
  - MrOwnPut 4y ago
    The difference in your analogy is he is currently working on an alternative (a good one imo), not only talking about it... His product is currently out there, popular, and already infinitely better than node (imo). I'm sorry you never "hit gold again", but you seem jaded and projecting that onto others. Who cares if it never fully overtakes node? It's a great alternative. Competition is good. I'd consider Deno a success already, it growing in popularity is always nice, but the tech already works.
    - joshmanders 4y ago
      > Who cares if it never fully overtakes node? It's a great alternative. Competition is good. I'd say the people who gave them $21M[0] care if it's adoption doesn't take off. [0]: https://deno.com/blog/series-a https://deno.com/blog/series-a
tsimionescu 4y ago
This is not (just) about adding a compatibility layer. The original deno presentation complained about the whole concept of a module that Node introduced (rather than "simply" referencing script files the way an HTML page does), it complained about the need of an additional file to specify imports etc. The blog post explains in detail why these things are actually required and useful, and introduces the new deno.js file that is functionally equivalent to package.json. So even purely deno packages meant to be used entirely in the deno ecosystem are encouraged to use the new package.json 2.0, for many of the same reasons package.json was introduced in Node all those years ago.

joshmanders 4y ago

Clearly you've never seen the at least 2 talks that Ryan Dahl has given about how he viewed package.json and npm as the two biggest blunders of Node's life and he was going to correct that in Deno. And here we are.

MrOwnPut 4y ago
I have, but you glossed over my point. What's wrong with a compatibility layer with npm if it's implemented properly? His views on package.json and implementing a compatibility layer to help others transition from node are not mutually exclusive. The support for node is pretty simple. Using NPM packages is straight forward. Reading a package.json file and using those mappings isn't complex either. Deno does not use node_modules in any of those instances...
- joshmanders 4y ago
  His point was that the mere ability was the issue, not some implementation. This is why Deno has gone so long without a true package manager. The problem here is now they're fighting for adoption so they're going against their original values because they know what they wanted isn't what the broader community wants.
  - MrOwnPut 4y ago
    > His point was that the mere ability was the issue Can you elaborate? > so they're going against their original values because they know what they wanted isn't what the broader community wants. No, they are still sticking to everything, but added support for the existing ecosystem. Yes they are adding this to combat the network effect that node has, but it doesn't really go against anything. You simply prefix npm in front of npm imports. Now you could use a package.json file if you already have one, but you don't have to.
    - tsimionescu 4y ago
      No. They are adding "deno:package@version" native imports, and they are adding a deno.json file to specify them. They are adding dependency resolution logic for these native deno packages to deno itself. The fact that all this interoperates with NPM as well is just an added bonus. But even if NPM died tomorrow, deno would go on having a package system, because they have realized how important it actually is (to fix things like what they call the "duplicate dependency problem").
      - MrOwnPut 4y ago
        Yes and that is nice, it'll allow future import map support, like in the browser, which is inline with Deno's goal of using browser APIs instead of proprietary ones. But the package.json format part is a backwards compatibility feature. The preferred import maps will be the ideal solution (if you do need dependency management). None of that really goes against direct imports, which work well for single file scripts, workers, etc. Choose what fits.
- hbn 4y ago
  The blog post didn't make it sound like this was implemented just for the sake of backwards compatibility, it sounds more like an admission that Deno's take on package management isn't a superior solution to how Node did it before.
  - MrOwnPut 4y ago
    Could you point out a few things in the blog that made it sound that way to you? It states many times it was added for backwards compatibility. Even at the bottom of TFA they annotate the ideal solution (which will be implemented soon) is to use import maps instead of package.json, the same format the browser uses, which is in line with Deno's main goals.
    - tsimionescu 4y ago
      You're ignoring the fact that, originally, deno wanted to eschew the concept of an import map entirely. They weren't against the format of package.json itself, or even against the fact that it's not a web standard. They were against the idea of having to specify imports sepeartely from your code, and against the idea of bundling multiple files into a concept of a module. Fast forward a few years, and they are now adding these two things natively to deno, just as the web ecosystem did. Turns out, Node was right to have modules and an import file all along, and at worst there were some minor implementation quibbles to argue about.
      - MrOwnPut 4y ago
        Personally I don't really care about the faux drama. I'm glad I can use direct url imports in simple Deno scripts. I also see the need for import maps for larger projects. I do think node_modules is an abomination and glad I don't have to deal with them anymore. I prefer writing everything that works in Deno and the browser, not Node specific APIs. I like the tech, I don't really care about the drama, and I doubt the Ryan does either lol.
        tsimionescu 4y ago
faitswulff 4y ago
From what I remember, Dahl considered node_modules one of the big blunders, which afaict they have avoided with Deno.
hombre_fatal 4y ago
Ryan Dahl's talk reminds me of the time I came back to a forum I created and then neglected after being distracted by university for four years. The forum had taken off while I was MIA. In spite of me being MIA. And while I could write a manifesto about how the forum had gone in a direction I didn't necessarily want, I had to admit that my plans for the forum weren't better nor more correct than the plans that emerged organically from the community over the years. When you create something with a community and ecosystem, it's easy to see the success of the ecosystem and the downstream success of the people within it as your success when in reality you are more like an early collaborator who set the stage for others to join in and take it from there. A good example of this in my case was the hubris that, because I created that one big forum, I could create more successful forums. I never hit gold again. I realized I wasn't some master forum creator, just someone who started something at the right time and the right place with just enough TLC to attract other builders, and that I didn't have some divine insight into how to start a successful forum. Oof.
- joshmanders 4y ago
  You hit the nail on the head here. This is exactly what's going on.
- MrOwnPut 4y ago
  The difference in your analogy is he is currently working on an alternative (a good one imo), not only talking about it... His product is currently out there, popular, and already infinitely better than node (imo). I'm sorry you never "hit gold again", but you seem jaded and projecting that onto others. Who cares if it never fully overtakes node? It's a great alternative. Competition is good. I'd consider Deno a success already, it growing in popularity is always nice, but the tech already works.
  - joshmanders 4y ago
    > Who cares if it never fully overtakes node? It's a great alternative. Competition is good. I'd say the people who gave them $21M[0] care if it's adoption doesn't take off. [0]: https://deno.com/blog/series-a https://deno.com/blog/series-a

tsimionescu 4y ago

This is not (just) about adding a compatibility layer. The original deno presentation complained about the whole concept of a module that Node introduced (rather than "simply" referencing script files the way an HTML page does), it complained about the need of an additional file to specify imports etc. The blog post explains in detail why these things are actually required and useful, and introduces the new deno.js file that is functionally equivalent to package.json. So even purely deno packages meant to be used entirely in the deno ecosystem are encouraged to use the new package.json 2.0, for many of the same reasons package.json was introduced in Node all those years ago.