3 ms·

1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? Why would you ship with node_modules? ALWAYS

by Otek 5y ago

1. yeah but mostly node is used as a server software. Python is much better as 'general purpose' right now 3. ????? Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.

throwaway894345 5y ago
> Python is much better as 'general purpose' right now Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful. > Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies. You've certainly convinced me that Deno's single binary deployment is a useful feature.
IggleSniggle 5y ago
1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's. 3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies. I haven't used CodeArtifact, but is it something you can deploy on-premise?
schwartzworld 5y ago
> yeah but mostly node is used as a server software. As a frontend dev, I use node tooling every day that has nothing to do with server code. > Python is much better as 'general purpose' Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem. That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever. Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable. But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.
megous 5y ago
Why ship node_modules? Because you want to ship the complete app. At least rsync comes to the rescue for quick deploy of 10000 tiny files remotely.
- whostolemyhat 5y ago
  That seems incredibly wasteful and time-consuming. You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks. Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.

by Otek 5y ago

throwaway894345 5y ago

> Python is much better as 'general purpose' right now Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful. > Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies. You've certainly convinced me that Deno's single binary deployment is a useful feature.

IggleSniggle 5y ago

1. I don't buy that python is necessarily much better as general purpose. It has a lot of great libraries for some specific things, but its performance is worse and its type story isn't nearly as good as TypeScript's. 3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies. I haven't used CodeArtifact, but is it something you can deploy on-premise?

schwartzworld 5y ago

> yeah but mostly node is used as a server software. As a frontend dev, I use node tooling every day that has nothing to do with server code. > Python is much better as 'general purpose' Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem. That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever. Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable. But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.

megous 5y ago

Why ship node_modules? Because you want to ship the complete app. At least rsync comes to the rescue for quick deploy of 10000 tiny files remotely.

whostolemyhat 5y ago
That seems incredibly wasteful and time-consuming. You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks. Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.