Hacker News new | ask | show | jobs
by aikah 4377 days ago
Well at least there is no possibility of conflicts(unlike some other pm). The problem is people writing modules that have like 1 function while requiring 10 other modules that have just 1 function themself that require 10*10 other modules ... Of course it doesnt scale,and of course the package manager wont scale either...

But it's not a NodeJS problem it is a NPM problem.NodeJS has other problems though(the lack of governance by a dedicated foundation is the most important one,the obvious second one is nodejs dependency on what google does/doesnt do,since google maintains V8).
2 comments
jeswin 4377 days ago
> second one is nodejs dependency on what google does/doesnt do,since google maintains V8

Google maintaining V8 is one of the big reasons why Node has been successful. There is no way an independent Node.JS foundation would have the resources to optimize and test JS like the Chrome team. So far, the problems have been minor and V8 has done a decent job keeping up with upcoming JS standards.

So this isn't a problem.

> 1 function while requiring 10 other modules that have just 1 function themself that require 10*10 other modules

As of now NPM is working (in spite of these problems) because those modules are tiny js files. I agree it would be beneficial to have better package management.

In fact, that's exactly what's giving me problems right now. My browserify task breaks due to the NoYieldInGenerator error in parsing. The dependency (esprima parser) has been patched upstream, but now that has to make its way into 4 dependencies inside browserify, and then browserify has to update itself. My alternative is to make 5 forks just to solve this. :/

It would have been great if they all used a single shared lib, and even better if I could manually override dependency versions of my dependencies.

link
aikah 4377 days ago
I wonder why Mozilla didnt/couldnt jump in the ship and propose a viable alternative to node/V8,I know there is a node/spidermonkey project somewhere but it isnt maintained.

V8 api changes made a lot of binary modules break and it will happen again,so it is a problem on the long run.Of course NodeJS team cant maintain V8.

But please dont throw that problem under the carpet,It's a real issue.

> Google maintaining V8 is one of the big reasons why Node has been successful.

Sure,but it doesnt guarantee Nodejs survival on the long run.Look, nodejs is an awesome project,i'm not here to question that fact.I use nodejs everyday I love it.I just cant trust Google on anything on the long run.

Do V8 team consult with nodejs team,listen to their suggestion ? (that a question).Is it a bidirectional relationship or a unilateral one?

link
brokenparser 4377 days ago
There exists "gjs" and "js" ("smjs" in Debian), both of which are being maintained.
link
cwmma 4377 days ago
TJ (the node lead) has suggested, fairly recently that making it easy to use other engine is something he is open to, at a node.js on the road event he mentioned that in his ideas for study so the line.
link
skeoh 4377 days ago
As far as I understand it the problem _is_ with Node -- specifically module.js [0] which is what defines require() and its recursive lookup behavior.

[0] https://github.com/joyent/node/blob/master/lib/module.js

link