3 ms·

I think there’s a universe in which Deno took off but it’s clearly not ours. I’m inclined to believe this is because what Deno is trying for, a more mature stan

I think there’s a universe in which Deno took off but it’s clearly not ours. I’m inclined to believe this is because what Deno is trying for, a more mature standards based and security focused version of the JavaScript ecosystem, isn’t what people use JavaScript for. Makes me sad because I really appreciate what they are trying to do.

tough 1y ago
Bun is really taking their lunch with a more simpler USP, "Faster"
pier25 1y ago
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.
- simlevesque 1y ago
 > 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.
 - MrJohz 1y ago
 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. :/
 - simlevesque 1y ago
 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>Hello world`); 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.
 - nwhit 1y ago
 Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues 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>Hello world <img src="https://example.com/logo.svg" />`, ); console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world" console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"
 - MrJohz 1y ago
 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.
- corytheboyd 1y ago
 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.
 - nwhit 1y ago
 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
 - corytheboyd 1y ago
 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.
 - pier25 1y ago
 > 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?
- pjmlp 1y ago
 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.
MrJohz 1y ago
I think Deno has done a good job pushing the ecosystem forwards, but I think it has the problem that anything it can do, NodeJS can also implement. Since Deno, NodeJS now follows most browser standards, also allows running Typescript natively, has a built-in test runner, and even has a similar permissions system to Deno (albeit behind an additional flag). I believe it can even import JSR modules if configured correctly. So NodeJS can do pretty much everything Deno can, but it also can do all the stuff it could already do.

tough 1y ago

Bun is really taking their lunch with a more simpler USP, "Faster"

pier25 1y ago

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.

simlevesque 1y ago
> 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.
- MrJohz 1y ago
 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. :/
 - simlevesque 1y ago
 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>Hello world`); 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.
 - nwhit 1y ago
 Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues 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>Hello world <img src="https://example.com/logo.svg" />`, ); console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world" console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"
 - MrJohz 1y ago
 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.
corytheboyd 1y ago
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.
- nwhit 1y ago
  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
  - corytheboyd 1y ago
    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.
  - pier25 1y ago
    > 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?
pjmlp 1y ago
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.

MrJohz 1y ago

I think Deno has done a good job pushing the ecosystem forwards, but I think it has the problem that anything it can do, NodeJS can also implement. Since Deno, NodeJS now follows most browser standards, also allows running Typescript natively, has a built-in test runner, and even has a similar permissions system to Deno (albeit behind an additional flag). I believe it can even import JSR modules if configured correctly. So NodeJS can do pretty much everything Deno can, but it also can do all the stuff it could already do.