Hacker News Reader

Comment by afavour | Hacker News Reader

I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.

View on HN

I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)

I previously worked at Deno and even with all that tbh, I am not sure the http deps were the right way to go. I've really wanted to like them but package managers really have advantages.

I would not say npm was the right direction. I actually was a fan of JSR (didn't work on it but all my experience with it was great)

As someone that works in projects with standard IT tools, not supporting NPM made it a non starter for us.

No way it would go through standard build pipelines, or team skills.

"standard" IT tools?

Yes, IT from customer, or agency delivery operations, dictates what are the official tools in specific projects, including 3rd party dependencies in internal repos, and CI/CD is cut off from accessing public Internet.

Oh, for sure. But I'm old enough to remember when standard IT tools would have never supported Node in the first place and the idea of JS on the server made everyone scream. You just need to build demand for that support.

For us the demand is, does it run everything that either Angular or Next.js require, or the SDKs from headless SaaS products.

Reply on news.ycombinator.com