4 ms·

Wow, very interested in an npm compatible Deno! I think that will remove a huge barrier to entry for Deno and could mark a huge shift towards usage in productio

Wow, very interested in an npm compatible Deno! I think that will remove a huge barrier to entry for Deno and could mark a huge shift towards usage in production. I'm very interested in how packages will manage runtime support in the future. Right now we are seeing an explosion of JavaScript runtimes from Cloudflare Workers to Bun, all with sightly different APIs. I wonder if there will be an easy way to get cross-runtime support without it being much extra work for library authors. Right now, there has already been conflict with some packages being browser-only and some being node-only. I feel like there needs to be a better solution than the one we have now.

adamddev1 4y ago
Yes the lack of npm compatibility was the only thing keeping me back from Deno. I really like they way they're going to do it. `import express from "npm:express@5";`
ricardobeat 4y ago
Both Deno and Bun are adopting APIs that are close to existing web standards, so Node is becoming the odd one out.
- montroser 4y ago
  There are _lots_ and _lots_ of JavaScript runtimes out there: https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
  - ricardobeat 4y ago
    I'm very familiar with the space. The majority of these have never reached production status or any meaningful usage, the few active ones are very niche products - Duktape, Espruino, Quickjs, etc, you'll be hard pressed to find someone running a web server, gui or cli app on them. Hermes might show up in the engine radar due to how prevalent RN is, but other than that, you can bet 99% of projects run Node.js or Deno now. As long as these are actual standards, all the other runtimes also get a fair shot at implementing them. I think it's a move in the right direction.
deckard1 4y ago
> browser-only and some being node-only. Browser, node (OS-level), or serverless worker, these are all fundamentally different roles and need different API requirements. Node and serverless don't have a DOM. Serverless can't have unfettered access to the host OS. Node should be as capable as any host language (Python, Ruby, C, etc.) with an API equally powerful. The browser obviously needs a more limited sandbox. There is a parallel universe out there, where Sun had success with Java in the browser, the JVM evolved to better support distribution and HTTP standards as well as replaced the need for WASM. And we all lived in a happy world with Java on the server and Java in the browser and everything is cross-platform and Just Works(tm). Cats and dogs also live together in harmony in this world. We had big dreams in the '90s.

adamddev1 4y ago

Yes the lack of npm compatibility was the only thing keeping me back from Deno. I really like they way they're going to do it. `import express from "npm:express@5";`

ricardobeat 4y ago

Both Deno and Bun are adopting APIs that are close to existing web standards, so Node is becoming the odd one out.

montroser 4y ago
There are _lots_ and _lots_ of JavaScript runtimes out there: https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
- ricardobeat 4y ago
  I'm very familiar with the space. The majority of these have never reached production status or any meaningful usage, the few active ones are very niche products - Duktape, Espruino, Quickjs, etc, you'll be hard pressed to find someone running a web server, gui or cli app on them. Hermes might show up in the engine radar due to how prevalent RN is, but other than that, you can bet 99% of projects run Node.js or Deno now. As long as these are actual standards, all the other runtimes also get a fair shot at implementing them. I think it's a move in the right direction.

deckard1 4y ago

> browser-only and some being node-only. Browser, node (OS-level), or serverless worker, these are all fundamentally different roles and need different API requirements. Node and serverless don't have a DOM. Serverless can't have unfettered access to the host OS. Node should be as capable as any host language (Python, Ruby, C, etc.) with an API equally powerful. The browser obviously needs a more limited sandbox. There is a parallel universe out there, where Sun had success with Java in the browser, the JVM evolved to better support distribution and HTTP standards as well as replaced the need for WASM. And we all lived in a happy world with Java on the server and Java in the browser and everything is cross-platform and Just Works(tm). Cats and dogs also live together in harmony in this world. We had big dreams in the '90s.