Hacker News Reader

Comment by z3t4 | Hacker News Reader

What's so special about NodeJS:

* It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.

There's nothing "revolutionary" about CommonJS. It's a packaging system that offers simple encapsulation (but so does Java/Kotlin/Scala or C#). There's something different about it, in that it allows concurrent use of different versions--but, frankly, to me that's a demerit, not a positive, 'cause I'd rather keep my dependencies squared away.

I believe there was a way to package and deploy apps with multiple versions of the same deps in the Java world before NodeJS came to be. I remember a buddy candidly explaining those capabilities to me, back when Rails gems were still managed with rake tasks.

OSGi, probably. Which is kind of hairy. But it's a difficult problem on the JVM.

NodeJS allows lexical (function) scoping of modules. I do not know any other language that allows this. Function scoping allows better decoupling when functions do not depend on the outer scope.

And modules in NodeJS are truly modular as they contain all their dependencies, even libraries.

The former: I'd like to know how this is better than, say, assembly-level scoping in a PCL in C#. It's different, but I wouldn't call it better, and I wouldn't say that it enables better decoupling--just decoupling at a different level.

The latter: as mentioned in my previous post, this is, to me, a misfeature. Transitive dependencies being encapsulated in a dependency increases the likelihood that those dependencies don't get fixed when bugs inevitably arise in those transitive dependencies. Do not want.

all variables in JS are private. Nodejs module require's are private in method scope. all modules in nodejs are open souece, when you find a bug you make a pull request. Popular modules are used by many, bugs tend to surface quickly. Semver versioning is used, so its usually safe to upgrade minor (bug fixes)

I'm not sure if you were building a case towards something, but I definitely don't get where you're going. Variables being private or not-private is not particularly meaningful to encapsulation while exports are relying on underscore-conventions to protect your internal state. Modules being open-source or not is not particularly relevant to either question, nor is semver when your transitive dependencies don't upgrade and so you're pulling in hard-to-audit transitive dependencies that may have red flags (and if your answer is "it's open-source, do it yourself", you have a very interesting view of what a developer should be spending time on).

All variables except those in the global scope are private, so you do not need underscore-conventions, simply do not declare the variable in the global scope! And when it comes to nodeJS modules, there are no global scope, all variables will be private unless explicitly exported. So instead of obj.__foo you just declare foo somewhere and it will not be possible to get or set it outside the module.

Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.

I think I'll have to make a blog post to explain it in more detail. And I encourage you to do the same ...

What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.

If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration. Software is special as it cost very little to copy code, so your one hour contribution can be copied many times creating a lot of value. It's like you would bake one cake once and it could be eaten many times, over and over again.

> All variables except those in the global scope are private, so you do not need underscore-conventions, simply do not declare the variable in the global scope! And when it comes to nodeJS modules, there are no global scope, all variables will be private unless explicitly exported. So instead of obj.__foo you just declare foo somewhere and it will not be possible to get or set it outside the module.

Alright, I get you now. I agree with you on this that it does allow for that sort of encapsulation--but, IMO, that's a bad kind of encapsulation; having to put fundamentally object-oriented data outside of the object strikes me as a profound routing around serious linguistic damage.

> Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.

This, OTOH, is pretty much the same as any language with any kind of encapsulation. Maybe ES modules have finally approached parity, but it's nothing special.

> What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.

Every dependency of your dependency is transitive. Just go look in the node_modules directory of any of your dependencies! If you require X and it requires Y and Z, bugs in its version of Y or Z are suddenly your problem. And its upgrade strategy becomes your problem, too.

OTOH, in something like Maven, saying "no, use my version of this transitive dependency" is very straightforward.

> If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration.

And my client doesn't care. If I'm working on my stuff, sure, I'll do that if it's the most efficient way to solve my problems. My clients do not give a single shit about this, though, and I have to build things they can deal with, not me.

So this is at best a misfeature. Primarily a bug.

Using open source software is usually faster. Practical example: The other day I needed to 1) Take a screen-shot of a web page, 2) Get a visual diff if it had changed, and the solution looked kinda like this:

  function takeScreenshot(webUrl) {
    var webshot = require('webshot');
    ...
  }

  function visualDiff(imgPath1, imgPath2) {
    var imageDiff = require('image-diff');
    ...
  }

I'm honestly not sure if this is sarcastic or not. CommonJS is just one approach to solve missing native modularization in JS, but not really revolutionary. Other languages usually have built-in features with a similar purpose, like "import" in Java or Python.

Couldn't you say the same thing about C? Or C++? Or really, any language made in the last 3 decades? (Except JavaScript which only got it recently and has several competing module/import mechanisms)

C/C++ has no module system to speak of. Libraries are packaged in a whole menagerie of ways and shapes, with different build systems and different ways of linking and including various parts of them.

Try building something with SDL on Windows if you want to see this for yourself.

Reply on news.ycombinator.com