5 ms·

Really? I think it is terrible when compared to other languages (C#, Java, Ruby, Python, etc...). I have only done a few applications on node, but my experience

by nahname 13y ago

Really? I think it is terrible when compared to other languages (C#, Java, Ruby, Python, etc...). I have only done a few applications on node, but my experience with including modules was painful to say the least.

RKoutnik 13y ago
Could you elaborate on that? What did you find difficult about `npm install $PACKAGE` and `var thing = require('thing')'`?
- regis 13y ago
  I personally found that some packages wouldn't install because they had dependencies that were broken in some way. This was about a year ago though, so I don't know how things have changed since then. Also, node packages seems to be small and specific so npm downloads many dependencies for each package. Again, I only played around with node for a little but I got a bit frustrated with all the packages and dependencies.
  - nonchalance 13y ago
    I think the issue you are describing really stems from poor semantic versioning. People will peg to specific revisions that they happen to use rather than depending on the general major or minor revision level, so small fixes don't naturally propagate to second- or third-level dependencies. There's no good solution to the problem that doesn't lead to other sorts of hell (imagine asking users to manage the revisions for third-level dependencies)
  - schuylerlarson 13y ago
    Might be worth your while to give it another shot. Npm is so lovely.
  - thedufer 13y ago
    Were you using Windows? Although node.js "works" on Windows, there are a number of modules that only compile under UNIX, which makes Windows basically useless for node development.
- nahname 13y ago
  Weird conventions, like including index.js by default. It does not play nicely with coffeescript's default behavior of including a module. The modules being a hack built into the language, I have to read library docs and follow external decisions (versus a holistic approach built by the language maintainer). Introducing a variable to contain a library is unconventional and potentially limiting (specifically for meta programming). Like I said, I didn't spend much time with them. They are a solution. NPM feels like the old rails gems and is certainly better than most package managers. Requiring external libraries and files specifically is a hack and feels as such. I would gladly take any of the languages inclusion techniques I listed above over node's. Edit: I am not trying to put down the hard work that went into creating the system. JavaScript does not support modules natively, so adding support is a momentous accomplishment. The unfortunate reality is that it will always be a limited solution. JavaScript modules (in any form) are going to be inferior to languages that natively support such a basic part of programming.
  - oakaz 13y ago
    index.js is not a default you need to include in your package. you better go read and experiment before making bullshit. JavaScript is a language with multiple platforms and NodeJS is just one of them.
    - brianmcd 13y ago
      I believe he's talking about node's behavior when requiring a folder: http://nodejs.org/api/modules.html#modules_folders_as_modules http://nodejs.org/api/modules.html#modules_folders_as_module...
  - warfangle 13y ago
    Don't complain about a tool built for Javascript when you try to shoehorn Coffeescript into it. Coffee script being a hack built into a new beast of a language, I have yet to read docs that drift from "JS is better! ... No, CS is better!" Use the right tools for the job, and don't complain that your pentagonal screwdriver doesn't always work on phillips head screws.
nobleach 13y ago
While I like using NuGet packages with C#, I'm not really wild about how they can get magically linked in to a project, and then required. I had nunit and fluent assertions become inextricable from a project I was working on even after all the tests were removed. Just a total mind-f*ck. Python when using pip is a whole lot better but I've had some issues finding things there too. Ruby... it depends. Are we talking Rails gemfile or "gem install $package"? Conflicting versions can become an issue. Java with Gradle has been pretty cool so far. NPM as a whole, has just worked. Packages are referenced in ONE place (package.json) I can do an "npm install $package --save" during development and it gets included automatically.
- usea 13y ago
  There's nothing magic going on. A C# project's settings are located in the .csproj file (other .net languages work similarly). This file is normally editied from within Visual Studio, but it's just xml and can be edited by hand fairly easily. A project file has references [1], which define the project's external dependences, Removing references is easy. [2][3] [1] http://msdn.microsoft.com/en-us/library/ez524kew(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/ez524kew(v=vs.110).a... [2] http://msdn.microsoft.com/en-us/library/hh708954.aspx http://msdn.microsoft.com/en-us/library/hh708954.aspx [3] http://msdn.microsoft.com/en-us/library/7314433t(v=vs.90).aspx http://msdn.microsoft.com/en-us/library/7314433t(v=vs.90).as...
- _random_ 13y ago
  Didn't understand the NuGet sentence. It's just binaries and XML descriptions. Worst case - just delete package.config and all the package folders. A one minute fix I used when not using source control to revert.
carrja99 13y ago
I'd have to say the biggest thing that npm has over module systems found in java, ruby, python etc. is the complete isolation of transitive dependencies. It is nice to use two dependencies and not waste a day or two because: * module A depends on module C v1.0.2 * module B depends on module C v1.4.3 In all the languages you mentioned it becomes a pain because you can only use one version of module C, meaning either module A or B simply will not work until you find a way around it.
- FooBarWidget 13y ago
  That's a property of Node/Javascript, not a property of NPM.
- k3n 13y ago
  That's great, but it's not without cost. Here, the cost is you end up with deeply-nested directory nodes (which breaks Jenkins ability to properly purge the directory after a job). Node modules are also extremely liberal in the number of files they create -- even a "simple" app using just a few common modules could end up with 1k+ extra files. This can produce problems in your IDE, as well as with your source control or continuous delivery systems, among other things. So, it solves some headaches, and creates others.
  - stdbrouw 13y ago
    Are your concerns more than just theoretical? I've been developing in Node for a long, long time now and have never had any issue with any of this. Take source control for instance: isn't the first thing you do to put `node_modules` in your gitignore?
    - zalew 13y ago
      some argue gitignoring node_modules http://www.futurealoof.com/posts/nodemodules-in-git.html http://www.futurealoof.com/posts/nodemodules-in-git.html
      - 13y ago
deleted 13y ago
[deleted]

by nahname 13y ago

RKoutnik 13y ago

Could you elaborate on that? What did you find difficult about `npm install $PACKAGE` and `var thing = require('thing')'`?

regis 13y ago
I personally found that some packages wouldn't install because they had dependencies that were broken in some way. This was about a year ago though, so I don't know how things have changed since then. Also, node packages seems to be small and specific so npm downloads many dependencies for each package. Again, I only played around with node for a little but I got a bit frustrated with all the packages and dependencies.
- nonchalance 13y ago
  I think the issue you are describing really stems from poor semantic versioning. People will peg to specific revisions that they happen to use rather than depending on the general major or minor revision level, so small fixes don't naturally propagate to second- or third-level dependencies. There's no good solution to the problem that doesn't lead to other sorts of hell (imagine asking users to manage the revisions for third-level dependencies)
- schuylerlarson 13y ago
  Might be worth your while to give it another shot. Npm is so lovely.
- thedufer 13y ago
  Were you using Windows? Although node.js "works" on Windows, there are a number of modules that only compile under UNIX, which makes Windows basically useless for node development.
nahname 13y ago
Weird conventions, like including index.js by default. It does not play nicely with coffeescript's default behavior of including a module. The modules being a hack built into the language, I have to read library docs and follow external decisions (versus a holistic approach built by the language maintainer). Introducing a variable to contain a library is unconventional and potentially limiting (specifically for meta programming). Like I said, I didn't spend much time with them. They are a solution. NPM feels like the old rails gems and is certainly better than most package managers. Requiring external libraries and files specifically is a hack and feels as such. I would gladly take any of the languages inclusion techniques I listed above over node's. Edit: I am not trying to put down the hard work that went into creating the system. JavaScript does not support modules natively, so adding support is a momentous accomplishment. The unfortunate reality is that it will always be a limited solution. JavaScript modules (in any form) are going to be inferior to languages that natively support such a basic part of programming.
- oakaz 13y ago
  index.js is not a default you need to include in your package. you better go read and experiment before making bullshit. JavaScript is a language with multiple platforms and NodeJS is just one of them.
  - brianmcd 13y ago
    I believe he's talking about node's behavior when requiring a folder: http://nodejs.org/api/modules.html#modules_folders_as_modules http://nodejs.org/api/modules.html#modules_folders_as_module...
- warfangle 13y ago
  Don't complain about a tool built for Javascript when you try to shoehorn Coffeescript into it. Coffee script being a hack built into a new beast of a language, I have yet to read docs that drift from "JS is better! ... No, CS is better!" Use the right tools for the job, and don't complain that your pentagonal screwdriver doesn't always work on phillips head screws.

nobleach 13y ago

While I like using NuGet packages with C#, I'm not really wild about how they can get magically linked in to a project, and then required. I had nunit and fluent assertions become inextricable from a project I was working on even after all the tests were removed. Just a total mind-f*ck. Python when using pip is a whole lot better but I've had some issues finding things there too. Ruby... it depends. Are we talking Rails gemfile or "gem install $package"? Conflicting versions can become an issue. Java with Gradle has been pretty cool so far. NPM as a whole, has just worked. Packages are referenced in ONE place (package.json) I can do an "npm install $package --save" during development and it gets included automatically.

usea 13y ago
There's nothing magic going on. A C# project's settings are located in the .csproj file (other .net languages work similarly). This file is normally editied from within Visual Studio, but it's just xml and can be edited by hand fairly easily. A project file has references [1], which define the project's external dependences, Removing references is easy. [2][3] [1] http://msdn.microsoft.com/en-us/library/ez524kew(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/ez524kew(v=vs.110).a... [2] http://msdn.microsoft.com/en-us/library/hh708954.aspx http://msdn.microsoft.com/en-us/library/hh708954.aspx [3] http://msdn.microsoft.com/en-us/library/7314433t(v=vs.90).aspx http://msdn.microsoft.com/en-us/library/7314433t(v=vs.90).as...
_random_ 13y ago
Didn't understand the NuGet sentence. It's just binaries and XML descriptions. Worst case - just delete package.config and all the package folders. A one minute fix I used when not using source control to revert.

carrja99 13y ago

I'd have to say the biggest thing that npm has over module systems found in java, ruby, python etc. is the complete isolation of transitive dependencies. It is nice to use two dependencies and not waste a day or two because: * module A depends on module C v1.0.2 * module B depends on module C v1.4.3 In all the languages you mentioned it becomes a pain because you can only use one version of module C, meaning either module A or B simply will not work until you find a way around it.

FooBarWidget 13y ago
That's a property of Node/Javascript, not a property of NPM.
k3n 13y ago
That's great, but it's not without cost. Here, the cost is you end up with deeply-nested directory nodes (which breaks Jenkins ability to properly purge the directory after a job). Node modules are also extremely liberal in the number of files they create -- even a "simple" app using just a few common modules could end up with 1k+ extra files. This can produce problems in your IDE, as well as with your source control or continuous delivery systems, among other things. So, it solves some headaches, and creates others.
- stdbrouw 13y ago
  Are your concerns more than just theoretical? I've been developing in Node for a long, long time now and have never had any issue with any of this. Take source control for instance: isn't the first thing you do to put `node_modules` in your gitignore?
  - zalew 13y ago
    some argue gitignoring node_modules http://www.futurealoof.com/posts/nodemodules-in-git.html http://www.futurealoof.com/posts/nodemodules-in-git.html
    - 13y ago

deleted 13y ago

[deleted]