3 ms·

Sorry, jQuery was a bad example - I remember jQuery not working in Node at all, but that was roughly 10 years ago. Things have improved. The fact remains that

Sorry, jQuery was a bad example - I remember jQuery not working in Node at all, but that was roughly 10 years ago. Things have improved. The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap. In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better. This is no surprise since web compat is a core goal of Deno. Node compat is not. > Wouldn't it be trivial to just fall back to checking node_modules for named packages? No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.

nikisweeting 6y ago
> Node compat is not. :'( That's a shame, it would make such a good node replacement with a great stdlib and Typescript support. I hope they reconsider in the future.
- mark_and_sweep 6y ago
  If Deno was only "Add TypeScript support", "Add security capabilities", and "Add URL imports", etc. it would simply be a new version (or multiple new versions) of Node. These (and other) disruptive breaking changes are about fixing mistakes that cannot be fixed (or at least, are hard to fix) in Node. Maybe, in a few years, you'll say something like "Oh, I wish legacy Node would be more Deno compatible" because Deno will be the de-facto server-side JS scripting runtime. Equally, it's possible that Deno will fail, but that many good ideas will be incorporated into Node as breaking changes. Node and Deno as well as their environments can grow further together or further apart. I think it's too early to tell which future is more likely.

nikisweeting 6y ago

> Node compat is not. :'( That's a shame, it would make such a good node replacement with a great stdlib and Typescript support. I hope they reconsider in the future.

mark_and_sweep 6y ago
If Deno was only "Add TypeScript support", "Add security capabilities", and "Add URL imports", etc. it would simply be a new version (or multiple new versions) of Node. These (and other) disruptive breaking changes are about fixing mistakes that cannot be fixed (or at least, are hard to fix) in Node. Maybe, in a few years, you'll say something like "Oh, I wish legacy Node would be more Deno compatible" because Deno will be the de-facto server-side JS scripting runtime. Equally, it's possible that Deno will fail, but that many good ideas will be incorporated into Node as breaking changes. Node and Deno as well as their environments can grow further together or further apart. I think it's too early to tell which future is more likely.