4 ms·

I'm actually a little disappointed by NPM compatibility. Or at least conflicted. Deno has felt like an opportunity to reboot the server-side JS ecosystem into s

I'm actually a little disappointed by NPM compatibility. Or at least conflicted. Deno has felt like an opportunity to reboot the server-side JS ecosystem into something far more sensible than it currently is. Not that anyone is to blame for what it is, really, but you learn lessons and move forward. Sometimes making breaking changes. This seems like an acceptance that moving on simply won't happen. The existing ecosystem is too big and too powerful to be ignored. If I were a particularly cynical person I'd also point to Deno taking on millions in VC funding - once you've done that you can't be content to create a perfect, gleaming sandbox. You have to bring in money.

lukevp 4y ago
I think this is the motivation behind requiring an npm: prefix. It is a way to virtue signal for devs who buy into the deno goals to push for migrating to non-“legacy” packages. If you see an npm: prefix in a deps.ts file you can consider it tech debt. And potentially set up a lint rule to enforce it in the future. If they had not put an explicit reference in the source (passed through the packages transparently or kept a server side list of packages on npm) then it wouldn’t be colocated with the source and the PR processes. I think this was a good move overall.
- brundolf 4y ago
  It's not just a "virtue signal"; those packages will have to go through some special (and pretty aggressive) transpiling in order to work. This wasn't just flipping a switch from the Deno team
  - bartlomieju 4y ago
    That's not really what's happening behind the scenes. We are consuming sources as they are provided in npm using "compat layer" that is part of Deno's standard library. We had to provide special module resolution, but besides polyfill for built-in Node APIs, it works very similar to how Node consumes these packages.
    - brundolf 4y ago
      Huh I didn't know about compatibility mode; sounds like a lot of the work had already been done then
      - bartlomieju 4y ago
        Yes, this effort started years ago and was ramped up significantly in recent months.
dimgl 4y ago
I can speak to this since I've used Deno quite a bit. The problem is that the Deno ecosystem is, unfortunately, still very young. This young age also brings a lot of instability with it. On the other hand, the Node ecosystem is extremely mature. There's a lot of legitimately great npm packages with years of development and bug fixes. Not being able to use these packages is a detriment to Deno's adoption, not a boon. IMO, the biggest issue with Node is Node itself, not its ecosystem. All Deno does is bring the JavaScript ecosystem to a more modern standard. Being able to pick and choose the npm packages you want to use while slowly adopting the Deno stdlib and Deno specific packages will make it easier for developers to make the switch. Once Deno ships these features I'll try Deno again. Right now I'm really turned off by JavaScript development. The last couple of times I've tried to start up a project on Node it's been an absolute nightmare with its ESM madness and lack of TypeScript support. On the other hand, getting started with Deno was a breath of fresh air... up until the real development starts.
- nobleach 4y ago
  This was my experience as well. When Fresh dropped a few weeks/months ago, I thought, "oh neat, islands architecture, that's right up my alley". I decided just to blindly fool around with it one weekend. I immediately was hit with, "but what do I do with my styles? How can I transform all this ancient Less into CSS and attach it to files/components?" I'm sure there's some sort of way around all that but, right now it seems like I'd need to have a node instance just to do a compilation step!
- Rezwoodly 4y ago
  How is Nodes biggest issue, Node? It eclipses any other JS runtime out there, and by a long way
  - dimgl 4y ago
    Node ESM support REALLY sucks. Node import maps suck (and are poorly documented). Node doesn't support TypeScript out of the box. Node dependency management has always sucked. I've used three different package managers, and I'm sure more will pop up in the future. I've always loved Node.js. But the unfortunate reality is it sucks to build new projects in it in 2022.
frabjoused 4y ago
Unfortunately it seems like it's this or Deno loses the race. It won't be useful if it dies.

lukevp 4y ago

I think this is the motivation behind requiring an npm: prefix. It is a way to virtue signal for devs who buy into the deno goals to push for migrating to non-“legacy” packages. If you see an npm: prefix in a deps.ts file you can consider it tech debt. And potentially set up a lint rule to enforce it in the future. If they had not put an explicit reference in the source (passed through the packages transparently or kept a server side list of packages on npm) then it wouldn’t be colocated with the source and the PR processes. I think this was a good move overall.

brundolf 4y ago
It's not just a "virtue signal"; those packages will have to go through some special (and pretty aggressive) transpiling in order to work. This wasn't just flipping a switch from the Deno team
- bartlomieju 4y ago
  That's not really what's happening behind the scenes. We are consuming sources as they are provided in npm using "compat layer" that is part of Deno's standard library. We had to provide special module resolution, but besides polyfill for built-in Node APIs, it works very similar to how Node consumes these packages.
  - brundolf 4y ago
    Huh I didn't know about compatibility mode; sounds like a lot of the work had already been done then
    - bartlomieju 4y ago
      Yes, this effort started years ago and was ramped up significantly in recent months.

dimgl 4y ago

I can speak to this since I've used Deno quite a bit. The problem is that the Deno ecosystem is, unfortunately, still very young. This young age also brings a lot of instability with it. On the other hand, the Node ecosystem is extremely mature. There's a lot of legitimately great npm packages with years of development and bug fixes. Not being able to use these packages is a detriment to Deno's adoption, not a boon. IMO, the biggest issue with Node is Node itself, not its ecosystem. All Deno does is bring the JavaScript ecosystem to a more modern standard. Being able to pick and choose the npm packages you want to use while slowly adopting the Deno stdlib and Deno specific packages will make it easier for developers to make the switch. Once Deno ships these features I'll try Deno again. Right now I'm really turned off by JavaScript development. The last couple of times I've tried to start up a project on Node it's been an absolute nightmare with its ESM madness and lack of TypeScript support. On the other hand, getting started with Deno was a breath of fresh air... up until the real development starts.

nobleach 4y ago
This was my experience as well. When Fresh dropped a few weeks/months ago, I thought, "oh neat, islands architecture, that's right up my alley". I decided just to blindly fool around with it one weekend. I immediately was hit with, "but what do I do with my styles? How can I transform all this ancient Less into CSS and attach it to files/components?" I'm sure there's some sort of way around all that but, right now it seems like I'd need to have a node instance just to do a compilation step!
Rezwoodly 4y ago
How is Nodes biggest issue, Node? It eclipses any other JS runtime out there, and by a long way
- dimgl 4y ago
  Node ESM support REALLY sucks. Node import maps suck (and are poorly documented). Node doesn't support TypeScript out of the box. Node dependency management has always sucked. I've used three different package managers, and I'm sure more will pop up in the future. I've always loved Node.js. But the unfortunate reality is it sucks to build new projects in it in 2022.

frabjoused 4y ago

Unfortunately it seems like it's this or Deno loses the race. It won't be useful if it dies.