Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By far my biggest issue with Node is the dependency on the fragile NPM ecosystem. I could be wrong but I think if Deno had tackled this problem head-on it would have become more popular.

Provide a framework or built-in libs which allow you to build a number of use cases (JSON API, etc) with as little dependencies as possible. That would be something much more valuable than becoming a Node replacement for the NPM ecosystem.

Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.



> Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.

These days there's almost nothing you can't do in Deno that you can do in Node. If you think there is, please reply here but I think that time has passed.


The thing I ran into today was jsdom not seeming to work at all in Deno.

My use case was trying to run Playwright to scrape a site, copy the resultant HTML into jsdom, then run Mozilla's `readability` module on that to get a summary of the page. I found a replacement for Playwright (astral), and `readability` seems to be runtime agnostic as long as it has access to DOM APIs, but jsdom doesn't work with Deno yet.

I'd love to hear if there's an alternative to jsdom that I could use, because I unfortunately can't switch entirely over to NodeJS in this particular project, so either I find a replacement server-side DOM library, or I need to juggle two runtimes for different parts of the project. :/


Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues) with some details and a reproduction?

All of the simple cases I've tried seem to work fine, e.g:

  import { JSDOM } from "npm:jsdom";
  
  const dom = new JSDOM(
    `<!DOCTYPE html><p>Hello world <img src="https://example.com/logo.svg" /></p>`,
  );
  
  console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world"
  console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"


Earlier today, it was producing an error that looked as if it couldn't render some elements. Unfortunately, I switched to a different branch where I tried to switch certain things over to Node, and now when I've switched back, there's a different error, now in the `readability` module, but still connected to its use of jsdom. It looks like it could be due to version mismatches — maybe readability requires a different version of JSDOM to the one installed by default — but now I'm trying to downgrade the currently installed version of JSDOM, and that doesn't seem to work — the version in deno.lock is stubbornly staying at the later version, despite having specified an older version in the `deno.jsonc` (and that older version appearing in the `workspace.dependencies` array at the bottom of the lock file).

I'll try again with a clearer head tomorrow, and maybe if I figure stuff out I can create a proper reproduction, but right now I don't know how to reproduce anything because it doesn't seem like my local environment is consistently reproducible, let alone trying to create something that would work on other machines. I'm surprised at how poor this behaviour is — I thought a big part of Deno@2 was to fix these sorts of dependency issues.


JSDOM works on Deno. Here's a script:

  // from https://gist.github.com/kt3k/6123515ff5d1e167f82dfe4aa12ee5d9
  import { JSDOM } from "https://jspm.dev/jsdom";
  const doc = new JSDOM(`<!DOCTYPE html><p>Hello world</p>`);
  console.log(doc.window.document.querySelector("p").textContent);
Run it like this:

  deno run 'https://gist.githubusercontent.com/kt3k/6123515ff5d1e167f82dfe4aa12ee5d9/raw/f27520c629e56ab6e53e411c455ecc289300bb28/jsdom-in-deno.ts'
This returns "Hello world" on my machine, deno 2.3.1

I'd need more info about your problem but I'm not convinced that Deno's the problem and if there is one.


That is the big issue with all these alternative implementations, I don't want to bother with compatibility issues, when I can use the original instead, including in regards to native modules tooling.


One of the original selling points of Deno seemed to be that it didn’t use NPM. It would build its own broadly useful and good standard library.

The NPM compatibility madness really does kill it for me. Probably something to do with taking VC money and “expanding addressable market” or whatever.


I don't think it's that complicated, in my mind it's as simple as the fact that the npm/node ecosystem is huge and not supporting it at all means having to reinvent each and every library that exists there. That is a huge task and in my experience, the lack of support for npm/node packages (used to) really hamper deno's usefulness.

Now you can tap into the npm ecosystem when needed, but still use deno-first libraries as you please. If you don't like npm, then you can ignore it entirely


But that’s exactly what I’m saying, a big selling point WAS reinventing things. There would be a stdlib “http” package for all HTTP client needs, an “orm” package, and so on. This is how I remember Deno being sold many years ago, and I thought it was a noble cause.


> If you don't like npm, then you can ignore it entirely

But what if Deno had invested all that Node compat effort into something else?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: