Hacker News Reader

Comment by RKoutnik | Hacker News Reader

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

View on HN

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.

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.

I see your point, but really, what he said about CoffeeScript doesn't make any sense. It doesn't have any 'default behaviour of including a module' because it's just syntax sugar, you use the same require() and libraries.

The default behavior for coffeescript is to hide the code in a JS module (the pattern). This is to prevent turning variables into globals. This behavior can be disabled, but I see it as one of the many benefits of coffeescript.

"JS modules" (what you're actually referring to are called IIFEs, which stands for "immediately-invoked function expressions" — JS modules are something else, and CoffeeScript doesn't support them) don't have anything to do with importing/exporting code. In browser-CoffeeScript the only way to "import" and "export" code is to make global whatever you intend to export.

IIFEs are also pretty orthogonal to Node's module system — they work perfectly fine together, and don't have much to do with each other at all. Not sure why you'd feel the need to disable IIFEs in the CoffeeScript compiler except out of desire for cleanliness since they're an ugly hack in the first place.

Could you provide an example scenario in which this would cause a problem? This has never had any noticeable effects in the 2 years I've been using Node and CoffeeScript together.

A closure. That's true, but it doesn't change the behavior inside a node module at all, they already have their own contained scope, you have access to the same globals `module/exports/global/require/etc`, and `this` is preserved.

Please don't confuse JS modules and closures, they are completely different things.

Fair points, though I quite like the concept of a "variable containing a library" (or module).

Personally, with JavaScript being the first language I seriously learned, it's intuitive for me to reason about. JavaScript is built around closures, and you're simply importing a closure that returns (exports) its public interface.

In fact, the main issue I have with ES6 modules is that they differentiate a "module object" from its default exports, which can be tricky to reason about (basically, what I wanted from ES6 modules was just syntactic sugar over CommonJS, whereas what we have is more powerful but more complex).

You do realise that CoffeeScript is just a layer of sugar/arsenic on top of JavaScript?

It's not clear to me how you can import something without adding it to one or more variables. I don't just mean in Node, I mean in any language.

Why do you feel node modules are a hack? They are part of node.js core and have very well-defined behavior. Most developers prefer them over the proposed `import` syntax in ES6.

I have nothing but praise for NPM - it's simple, fast, keeps dependencies isolated (but can dedupe if wanted), and did I mention fast? It runs circles around any other package manager I've used, except maybe for homebrew.

You can implement a module pattern with closures quite easily.

Which is not the same thing as node's modules. There's nothing stopping me from making global variables within a module "pattern". Contrast that with a node.js module where even if a variable declaration leaves out a 'var' by accident, the global will not show up in anything that imports that module. I.e., there is no chance of name collisions because each node module gets its own unique and clean global scope.

True, but the question was whether JS had any native ways to support modules, and closures are literally right there. That's a good way to start them. Add more shit on top to make it robust, but they're still there.

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.

I believe he's talking about node's behavior when requiring a folder: http://nodejs.org/api/modules.html#modules_folders_as_module...

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.

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)

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.

Might be worth your while to give it another shot. Npm is so lovely.

Reply on news.ycombinator.com