3 ms·

Why? Are you avoiding NPM as well? Seems like a curious requirement for JS development

by tln 7y ago

minieggs 7y ago
Yes. I would prefer the only JavaScript VM on my computer to be the browser's. Aside: I wouldn't sell what I do as JavaScript development, though.
- z3t4 7y ago
  For the last 25 years, many apps have come with their own JS engine for scripting abilities. Ms Office, Photoshop, et. al. Not just the web browser. And more and more "native" apps have a built in JS engine. And then there's apps that not only have a JS engine, but a whole browser (Electron, Nw.js). So it would be difficult to purge your system from anything that can run JS :P
mattlondon 7y ago
I avoid NPM if I can for JS development (after all not all JS/TS development requires NodeJS) so it is painful to see people use npm as the installation method for their projects or tools when I am trying to write something simple. For what it is worth, the replacement for NodeJS (Deno) is removing the use of npm, so I am not alone in my dislike of the centralised registry idea it seems.
- fictionfuture 7y ago
  Deno will fail at this, they are fixing something that isn't broken.
  - ss3000 7y ago
    IMHO, Deno's approach to package management, that is to say, no package management ("packages" are just source files that you'd import directly using urls or file paths), is a breath of fresh air compared to the status quo in node where to import some javascript that's already hosted at some url (say on github), you first have to "package" it by describing it with some manifest, uploading it to some registry at a different url than the original, and then "install" it using a package manager from that other url, and at the end of the day not even have any guarantee that the content of that thing you installed actually matches what you saw at the original url. Deno's approach on the other hand is doesn't force any of that indirection onto the user, and is analogous to (and compatible with) the model of modules on the web. Package management systems can be easily layered on top of that if the use case actually warrants that extra indirection, rather than having it baked into the core of the runtime.

Why? Are you avoiding NPM as well? Seems like a curious requirement for JS development

by tln 7y ago

Why? Are you avoiding NPM as well? Seems like a curious requirement for JS development

Yes. I would prefer the only JavaScript VM on my computer to be the browser's. Aside: I wouldn't sell what I do as JavaScript development, though.

z3t4 7y ago
For the last 25 years, many apps have come with their own JS engine for scripting abilities. Ms Office, Photoshop, et. al. Not just the web browser. And more and more "native" apps have a built in JS engine. And then there's apps that not only have a JS engine, but a whole browser (Electron, Nw.js). So it would be difficult to purge your system from anything that can run JS :P

mattlondon 7y ago

I avoid NPM if I can for JS development (after all not all JS/TS development requires NodeJS) so it is painful to see people use npm as the installation method for their projects or tools when I am trying to write something simple. For what it is worth, the replacement for NodeJS (Deno) is removing the use of npm, so I am not alone in my dislike of the centralised registry idea it seems.

fictionfuture 7y ago
Deno will fail at this, they are fixing something that isn't broken.
- ss3000 7y ago
  IMHO, Deno's approach to package management, that is to say, no package management ("packages" are just source files that you'd import directly using urls or file paths), is a breath of fresh air compared to the status quo in node where to import some javascript that's already hosted at some url (say on github), you first have to "package" it by describing it with some manifest, uploading it to some registry at a different url than the original, and then "install" it using a package manager from that other url, and at the end of the day not even have any guarantee that the content of that thing you installed actually matches what you saw at the original url. Deno's approach on the other hand is doesn't force any of that indirection onto the user, and is analogous to (and compatible with) the model of modules on the web. Package management systems can be easily layered on top of that if the use case actually warrants that extra indirection, rather than having it baked into the core of the runtime.