Looks interesting but way too early to tell if it will have legs. I am a little uneasy about having a global cache of modules that can be overwritten by any project started with a --reload flag....
Looks interesting but way too early to tell if it will have legs.
I am a little uneasy about having a global cache of modules that can be overwritten by any project started with a --reload flag. It should be fine so long as all projects' dependencies follow semver properly... but when has that always been the case.
Also been thinking about URL imports, it sounds like it might be a pain in the but changing versions of things if it's being imported all over you app. I feel like most are going to end up with a...
Also been thinking about URL imports, it sounds like it might be a pain in the but changing versions of things if it's being imported all over you app. I feel like most are going to end up with a single config file similar to package.json where you alias your dependencies.
This is a talk given yesterday by Ryan Dahl, one of the main original contributors to Node/NPM. tl;dw (thanks to /u/vosper on lobste.rs) Removing Promises after they were initially added to Node....
This is a talk given yesterday by Ryan Dahl, one of the main original contributors to Node/NPM.
Removing Promises after they were initially added to Node. They should have been left in.
There’s virtually no security. V8 has a very good sandbox, which could have been maintained for server-side applications
The build system (GYP): Chrome used to use it, but moved on, now Node is the sole user:
“it’s a very funky interface […] it’s very terrible”
“it’s an awful experience for users”
“the continued use of GYP is probably the largest failure of node core”
package.json led to NPM being sanctioned, and there being a centralized repo for JS packages (Ryan doesn’t explain why this is a regret).
“It gives rise to this concept of a ‘module’ as a directory of files, which wasn’t a concept before, when we just had Javascript files […] it’s not a strictly necessary abstraction”
“package.json has all this unnecessary noise in it”
node_modules:
“it massively complicates the module resolution algorithm”
“deviates greatly from browser semantics”
“In practice a $NODE_PATH, like $PYTHON_PATH, would have worked, you can do vendoring that way too.”
“require” without the extension (eg “.js”)
“Why? It just makes things more complicated”
“index.js”
“I thought it was cute, because there was index.html”;
“it needlessly complicates the module loading system”;
“One thing I’ve learned as I’m aging is that whenever you’re designing a program there’s things that you think might be cute to add in. You always regret those”.
Looks interesting but way too early to tell if it will have legs.
I am a little uneasy about having a global cache of modules that can be overwritten by any project started with a
--reloadflag. It should be fine so long as all projects' dependencies follow semver properly... but when has that always been the case.Also been thinking about URL imports, it sounds like it might be a pain in the but changing versions of things if it's being imported all over you app. I feel like most are going to end up with a single config file similar to package.json where you alias your dependencies.
This is a talk given yesterday by Ryan Dahl, one of the main original contributors to Node/NPM.
tl;dw (thanks to /u/vosper on lobste.rs)
Removing Promises after they were initially added to Node. They should have been left in.
There’s virtually no security. V8 has a very good sandbox, which could have been maintained for server-side applications
The build system (GYP): Chrome used to use it, but moved on, now Node is the sole user:
“it’s a very funky interface […] it’s very terrible”
“it’s an awful experience for users”
“the continued use of GYP is probably the largest failure of node core”
package.json led to NPM being sanctioned, and there being a centralized repo for JS packages (Ryan doesn’t explain why this is a regret).
“It gives rise to this concept of a ‘module’ as a directory of files, which wasn’t a concept before, when we just had Javascript files […] it’s not a strictly necessary abstraction”
“package.json has all this unnecessary noise in it”
node_modules:
“it massively complicates the module resolution algorithm”
“deviates greatly from browser semantics”
“In practice a $NODE_PATH, like $PYTHON_PATH, would have worked, you can do vendoring that way too.”
“require” without the extension (eg “.js”)
“Why? It just makes things more complicated”
“index.js”
“I thought it was cute, because there was index.html”;
“it needlessly complicates the module loading system”;
“One thing I’ve learned as I’m aging is that whenever you’re designing a program there’s things that you think might be cute to add in. You always regret those”.