3 ms·

What's so special about NodeJS: * It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.

by z3t4 10y ago

statictype 10y ago
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)
- nornagon 10y ago
  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.
eropple 10y ago
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.
- some1else 10y ago
  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.
  - eropple 10y ago
    OSGi, probably. Which is kind of hairy. But it's a difficult problem on the JVM.
- z3t4 10y ago
  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.
  - eropple 10y ago
    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.
    - z3t4 10y ago
      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)
      - eropple 10y ago
        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).
        10y ago
blauditore 10y ago
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.

What's so special about NodeJS: * It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.

by z3t4 10y ago

What's so special about NodeJS: * It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.

statictype 10y ago

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)

nornagon 10y ago
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.

eropple 10y ago

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.

some1else 10y ago
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.
- eropple 10y ago
  OSGi, probably. Which is kind of hairy. But it's a difficult problem on the JVM.
z3t4 10y ago
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.
- eropple 10y ago
  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.
  - z3t4 10y ago
    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)
    - eropple 10y ago
      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).
      - 10y ago

blauditore 10y ago

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.