4 ms·

> “[...] Drop whatever you are doing because it’s not important. What is important is OUR time” > Most NPM packages NPM packages tend to be free and open sour

> “[...] Drop whatever you are doing because it’s not important. What is important is OUR time” > Most NPM packages NPM packages tend to be free and open source so morally they don’t owe us anything. So yes what is important is the time of the authors of the packages. I am grateful someone took the trouble to release them and many popular ones are actually well maintained. But cloud services that you are paying for are a totally different ball game. The company does need to maintain backwards compatibility for a good amount time and they need to value your time.

murgindrag 6y ago
I don't care about moral debts or obligations. I care about whether stuff works and I can get shit done. Other ecosystems (like Python) don't have the same culture as NPM. There are clean, well-documented, maintained packages. Google doesn't have a moral obligation to support GCE customers either. It's just that everyone I know who has used GCE would never use it in production, and loudly advises everyone they know not to do so either. They'll be bleeding money at some point, not to mention they're already bleeding reputation. Google went from smartest-people-in-the-room to smug-incompetent-arrogant-douchebags. That's hard to get over. That's about good business, not some kind of moral obligation.
- KingOfCoders 6y ago
  Same for Java.
nicoffeine 6y ago
I recently returned to dev work after years in a niche of systems administration in banking and healthcare. The existing product is built on npm, and after a month in, I'm simply disappointed that such a fragile set of software is this popular. Almost every day there is an automated PR to bump one of the thousands of dependencies. LTS is ending for Angular 8, but one of the main component dependencies doesn't support 9 yet. I had to put typescript in an unsupported state so one of the dependency upgrades wouldn't break something -- the solution is an ugly hack not supported by anyone. Another required a bump to lodash, which suddenly started failing. This led me to the following comment in a github thread: > The recursive implementation of cloneDeep was by design with the shortcoming that in some rare cases it could run into stack size exceeded issues. I'm not how cloneDeep is being used but chances are a more specialized clone tailored to their scenario will be a better option. So, I agree with the OP: the messaging for support in the npm world can be distilled to "fuck you". If I had ever proposed to a customer that we would build infrastructure for them written by thousands of pseudo-anonymous entities who may or may not break everything because they felt like it, I would have correctly been fired. This leads me to believe that supportability, reliability, and security aren't important to the npm ecosystem because ultimately the products built with npm don't matter. A bank or a utility company may use them to build a customer facing application, but for the stuff that's important, a competent technology manager would never let npm through the door. (edit: I replaced "tools" with "software" in the first paragraph, because tools don't change interfaces and effects on a whim).

murgindrag 6y ago

I don't care about moral debts or obligations. I care about whether stuff works and I can get shit done. Other ecosystems (like Python) don't have the same culture as NPM. There are clean, well-documented, maintained packages. Google doesn't have a moral obligation to support GCE customers either. It's just that everyone I know who has used GCE would never use it in production, and loudly advises everyone they know not to do so either. They'll be bleeding money at some point, not to mention they're already bleeding reputation. Google went from smartest-people-in-the-room to smug-incompetent-arrogant-douchebags. That's hard to get over. That's about good business, not some kind of moral obligation.

KingOfCoders 6y ago
Same for Java.

nicoffeine 6y ago

I recently returned to dev work after years in a niche of systems administration in banking and healthcare. The existing product is built on npm, and after a month in, I'm simply disappointed that such a fragile set of software is this popular. Almost every day there is an automated PR to bump one of the thousands of dependencies. LTS is ending for Angular 8, but one of the main component dependencies doesn't support 9 yet. I had to put typescript in an unsupported state so one of the dependency upgrades wouldn't break something -- the solution is an ugly hack not supported by anyone. Another required a bump to lodash, which suddenly started failing. This led me to the following comment in a github thread: > The recursive implementation of cloneDeep was by design with the shortcoming that in some rare cases it could run into stack size exceeded issues. I'm not how cloneDeep is being used but chances are a more specialized clone tailored to their scenario will be a better option. So, I agree with the OP: the messaging for support in the npm world can be distilled to "fuck you". If I had ever proposed to a customer that we would build infrastructure for them written by thousands of pseudo-anonymous entities who may or may not break everything because they felt like it, I would have correctly been fired. This leads me to believe that supportability, reliability, and security aren't important to the npm ecosystem because ultimately the products built with npm don't matter. A bank or a utility company may use them to build a customer facing application, but for the stuff that's important, a competent technology manager would never let npm through the door. (edit: I replaced "tools" with "software" in the first paragraph, because tools don't change interfaces and effects on a whim).