4 ms·

It's become clear that it's a hard requirement for wide adoption, especially with the new competition from bun. Personal anecdote: I tried to pitch Deno last ye

It's become clear that it's a hard requirement for wide adoption, especially with the new competition from bun. Personal anecdote: I tried to pitch Deno last year at my job, and as soon as I mentioned that it can't use the NPM ecosystem they went "ahh..." and the conversation basically stopped. So I don't blame the team for being practical. You can still make things better without a clean break

lolinder 3y ago
> especially with the new competition from bun Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. They could have chosen to let bun take the npm-compatibility crowd and stick to their guns, but VC funding precludes that.
- brundolf 3y ago
  You're making some bad-faith assumptions. Ecosystems die without adoption. A runtime that plugs its ears to the practical needs of users is a runtime that nobody but enthusiasts ever use. And you can't build any kind of sustainable business on an enthusiast-only runtime, VC or no VC. Idealism requires pragmatism to succeed.
  - toastercat 3y ago
    I don't disagree with your general sentiment, but you can be pragmatic and useful to users without bending to their every need. It's doesn't mean you're plugging your ears, it means you're being careful. Node and NPM are moving targets; chasing compatibility itself is not practical, and Dahl explicitly mentioned in his intro to Deno that Node compatibility was not a great idea (he was right). If your team/company is reliant on Node packages, it does not make any sense to go for another runtime.
    - pavon 3y ago
      There is a difference between Node compatibility and NPM compatibility though. NPM may have started with Node, but it has become part of the core development process for front-end web development. One of the main purposes of Deno is to decrease the gap between frontend JS development and backend JS development, and adding NPM support furthers that goal. What doesn't make sense is adding a compatibility layer for all the Node specific functionality that has since become redundant with new Web standards.
      - tracker1 3y ago
        Given that a significant number of packages in npm won't work without Node compatibility, I'm not sure the distinction makes much of a difference.
    - jitl 3y ago
      > If your team/company is reliant on Node packages, it does not make any sense to go for another runtime If Deno does some things better than node, and nothing worse, then NPM support means users can gradually migrate from node. Any of those improvements might be enough motivation if they help your use-case. AFAICT, there still isn’t a killer reason for my mature project to migrate, but removing the NPM blocker means I can consider it as soon as they release something that fits my use case.
    - brundolf 3y ago
      Here's an example where NPM compatibility allowed me to use Deno where I otherwise couldn't: I've got a personal blog that had been on Node. I wanted to port it to Deno. I ported all the server code to be Deno-idiomatic, I dropped dependencies in favor of Deno standard library functions etc, it was great. But I needed a markdown parser with specific special features that my corpus of existing documents already used. I researched Deno-native ones, I found one or two half-baked markdown parsers but none that supported the features I needed. So, with a little fiddling, I got the (mature, featureful) NPM markdown library I'd been using before, working directly within the Deno version of my site. Markdown in -> HTML out. Everything else is lovely pure Deno code, and this one small piece of functionality didn't become a show-stopper because the team chose to support what I needed. I tend to be an idealist in my programming - that's why I like Deno - but the absolutism I'm seeing in this thread is bizarre. An ecosystem is a huge asset, and you don't rebuild one - especially one as vibrant as NPM - overnight. It takes time, and in that time people can stop caring about your runtime and just use another one so they can get on with their lives. Projects like Deno are beholden to network effects; if you shun the network, the project dies.
      - toastercat 3y ago
        That is a weird example, because you make it sound like you easily could have just extracted the Deno-compatible JS, and made a regular ECMAScript Module and avoided an NPM compatibility layer at all. In fact, I did this exact thing to use marked[1] with QuickJS[2]. Obviously, QuickJS doesn't have an NPM compatibility layer because it doesn't need one, and neither does Deno. The great thing is the resulting .js file can easily be a Deno module as well. > I tend to be an idealist in my programming - that's why I like Deno - but the absolutism I'm seeing in this thread is bizarre I don't really see any absolutism in this thread, it's just a disagreement. Yes, NPM compat is great for adoption. I'm arguing it's not great for the runtime, and that it adds tech debt, and slows the team down from doing (imo) more creative things. It also adds more to the binary. [1] https://raw.githubusercontent.com/markedjs/marked/master/lib/marked.esm.js https://raw.githubusercontent.com/markedjs/marked/master/lib... [2] https://bellard.org/quickjs/quickjs.html https://bellard.org/quickjs/quickjs.html
        3y ago
- 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.

lolinder 3y ago

> especially with the new competition from bun Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. They could have chosen to let bun take the npm-compatibility crowd and stick to their guns, but VC funding precludes that.

brundolf 3y ago
You're making some bad-faith assumptions. Ecosystems die without adoption. A runtime that plugs its ears to the practical needs of users is a runtime that nobody but enthusiasts ever use. And you can't build any kind of sustainable business on an enthusiast-only runtime, VC or no VC. Idealism requires pragmatism to succeed.
- toastercat 3y ago
  I don't disagree with your general sentiment, but you can be pragmatic and useful to users without bending to their every need. It's doesn't mean you're plugging your ears, it means you're being careful. Node and NPM are moving targets; chasing compatibility itself is not practical, and Dahl explicitly mentioned in his intro to Deno that Node compatibility was not a great idea (he was right). If your team/company is reliant on Node packages, it does not make any sense to go for another runtime.
  - pavon 3y ago
    There is a difference between Node compatibility and NPM compatibility though. NPM may have started with Node, but it has become part of the core development process for front-end web development. One of the main purposes of Deno is to decrease the gap between frontend JS development and backend JS development, and adding NPM support furthers that goal. What doesn't make sense is adding a compatibility layer for all the Node specific functionality that has since become redundant with new Web standards.
    - tracker1 3y ago
      Given that a significant number of packages in npm won't work without Node compatibility, I'm not sure the distinction makes much of a difference.
  - jitl 3y ago
    > If your team/company is reliant on Node packages, it does not make any sense to go for another runtime If Deno does some things better than node, and nothing worse, then NPM support means users can gradually migrate from node. Any of those improvements might be enough motivation if they help your use-case. AFAICT, there still isn’t a killer reason for my mature project to migrate, but removing the NPM blocker means I can consider it as soon as they release something that fits my use case.
  - brundolf 3y ago
    Here's an example where NPM compatibility allowed me to use Deno where I otherwise couldn't: I've got a personal blog that had been on Node. I wanted to port it to Deno. I ported all the server code to be Deno-idiomatic, I dropped dependencies in favor of Deno standard library functions etc, it was great. But I needed a markdown parser with specific special features that my corpus of existing documents already used. I researched Deno-native ones, I found one or two half-baked markdown parsers but none that supported the features I needed. So, with a little fiddling, I got the (mature, featureful) NPM markdown library I'd been using before, working directly within the Deno version of my site. Markdown in -> HTML out. Everything else is lovely pure Deno code, and this one small piece of functionality didn't become a show-stopper because the team chose to support what I needed. I tend to be an idealist in my programming - that's why I like Deno - but the absolutism I'm seeing in this thread is bizarre. An ecosystem is a huge asset, and you don't rebuild one - especially one as vibrant as NPM - overnight. It takes time, and in that time people can stop caring about your runtime and just use another one so they can get on with their lives. Projects like Deno are beholden to network effects; if you shun the network, the project dies.
    - toastercat 3y ago
      That is a weird example, because you make it sound like you easily could have just extracted the Deno-compatible JS, and made a regular ECMAScript Module and avoided an NPM compatibility layer at all. In fact, I did this exact thing to use marked[1] with QuickJS[2]. Obviously, QuickJS doesn't have an NPM compatibility layer because it doesn't need one, and neither does Deno. The great thing is the resulting .js file can easily be a Deno module as well. > I tend to be an idealist in my programming - that's why I like Deno - but the absolutism I'm seeing in this thread is bizarre I don't really see any absolutism in this thread, it's just a disagreement. Yes, NPM compat is great for adoption. I'm arguing it's not great for the runtime, and that it adds tech debt, and slows the team down from doing (imo) more creative things. It also adds more to the binary. [1] https://raw.githubusercontent.com/markedjs/marked/master/lib/marked.esm.js https://raw.githubusercontent.com/markedjs/marked/master/lib... [2] https://bellard.org/quickjs/quickjs.html https://bellard.org/quickjs/quickjs.html
      - 3y ago
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.