5 ms·

> Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. Can you explain in your own words why sup

by roqi 3y ago

> Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. Can you explain in your own words why supporting the world's leading package manager system makes Deno "drop what makes it special"? Does it make any sense to argue against gaining access to all conceivable dependencies?

lolinder 3y ago
I'll do you one better, and explain it in Ryan Dahl's words [0]. Getting away from NPM, node_modules, and package.json was one of a very small number of founding principles for Deno as he introduced it: > Linking to a package requires a lot of components, a lot of systems. The problem that I have with [package.json] is that it gives rise to this concept of a module as this directory of files, where that wasn't really a concept before, where we just had JavaScript files. ... It's not a strictly necessary abstraction. And package.json has all this unnecessary noise in it. > ... > [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software. [0] https://youtu.be/M3BM9TB-8yA?t=1256 https://youtu.be/M3BM9TB-8yA?t=1256
- roqi 3y ago
  [flagged]
  - deleted 3y ago
    [deleted]
  - lolinder 3y ago
    I linked to the second half of the quotation. The first half was far from a passing comment, he spends a solid 3 minutes on his substantial problems with package.json: https://youtu.be/M3BM9TB-8yA?t=589 https://youtu.be/M3BM9TB-8yA?t=589 That first half is essential for understanding the second half. It sounds like a passing comment if you didn't watch both segments because he's assuming you already have the context for why he's ditching node. Since you're assuming bad faith I won't be monitoring this thread any more. If you'd like to have longer, substantive discussions on HN, I'd suggest knocking off the name calling.
- tomjakubowski 3y ago
  > The problem that I have with [package.json] is that it gives rise to this concept of a module as this directory of files, where that wasn't really a concept before, where we just had JavaScript files > > [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software. I think that Deno's module system is still incompatible with Node's: supplying a node_modules directory of files in your project root, at run time or at build time, still won't work. Deno is now just doing the work to ingest npm packages and process them into Deno modules at build time, if you want to use them. That doesn't seem out of line with Dahl's vision to me.
rhaway84773 3y ago
Turns out, in the real world, arbitrary complexity under the hood which is almost completely invisible to the user, is less of a drawback than not having access to the largest ecosystem of 3rd party libraries that exist for the platform. I greatly prefer a project that is willing to reconsider its founding principles than sticking dogmatically to them even when they are being harmful to the project and its users.
- roqi 3y ago
  You make a great point. No matter how high the complexity level is, if interfaces and abstractions are trivial to follow and they "just work" then the system is actually simple and trivial. I'm seeing poorly advised commenters in this thread trying to argue that reinventing the wheel is simpler than just using industry standards that are readily available and "just work".
pxc 3y ago
> the world's leading package manager system What, exactly, do you mean by this? Just that NPM is where the most publicly available JavaScript code lives?

by roqi 3y ago

lolinder 3y ago

I'll do you one better, and explain it in Ryan Dahl's words [0]. Getting away from NPM, node_modules, and package.json was one of a very small number of founding principles for Deno as he introduced it: > Linking to a package requires a lot of components, a lot of systems. The problem that I have with [package.json] is that it gives rise to this concept of a module as this directory of files, where that wasn't really a concept before, where we just had JavaScript files. ... It's not a strictly necessary abstraction. And package.json has all this unnecessary noise in it. > ... > [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software. [0] https://youtu.be/M3BM9TB-8yA?t=1256 https://youtu.be/M3BM9TB-8yA?t=1256

roqi 3y ago
[flagged]
- deleted 3y ago
  [deleted]
- lolinder 3y ago
  I linked to the second half of the quotation. The first half was far from a passing comment, he spends a solid 3 minutes on his substantial problems with package.json: https://youtu.be/M3BM9TB-8yA?t=589 https://youtu.be/M3BM9TB-8yA?t=589 That first half is essential for understanding the second half. It sounds like a passing comment if you didn't watch both segments because he's assuming you already have the context for why he's ditching node. Since you're assuming bad faith I won't be monitoring this thread any more. If you'd like to have longer, substantive discussions on HN, I'd suggest knocking off the name calling.
tomjakubowski 3y ago
> The problem that I have with [package.json] is that it gives rise to this concept of a module as this directory of files, where that wasn't really a concept before, where we just had JavaScript files > > [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software. I think that Deno's module system is still incompatible with Node's: supplying a node_modules directory of files in your project root, at run time or at build time, still won't work. Deno is now just doing the work to ingest npm packages and process them into Deno modules at build time, if you want to use them. That doesn't seem out of line with Dahl's vision to me.

rhaway84773 3y ago

Turns out, in the real world, arbitrary complexity under the hood which is almost completely invisible to the user, is less of a drawback than not having access to the largest ecosystem of 3rd party libraries that exist for the platform. I greatly prefer a project that is willing to reconsider its founding principles than sticking dogmatically to them even when they are being harmful to the project and its users.

roqi 3y ago
You make a great point. No matter how high the complexity level is, if interfaces and abstractions are trivial to follow and they "just work" then the system is actually simple and trivial. I'm seeing poorly advised commenters in this thread trying to argue that reinventing the wheel is simpler than just using industry standards that are readily available and "just work".

pxc 3y ago

> the world's leading package manager system What, exactly, do you mean by this? Just that NPM is where the most publicly available JavaScript code lives?