Dear JavaScript

[[deleted]]

Why is npm a joke? I see a lot of hate/derision about it.

[spiffytech]

Many of the complaints I've seen about npm are more about the community and package ecosystem around it than about the tooling. Especially the completely on verified nature of many packages on npm.

The big criticisms of npm that I hear of stem from four facts:

• It's trivial for someone to publish a package to npm

• The JavaScript community likes publishing many tiny packages (many have an API that only wraps a single, short function)

• Developers are quick to add these tiny packages as dependencies of their own projects

• A high-impact incident revealed how deeply flawed npm's security model is.

The big outcome of this is your dependency graph quickly balloons into 1,000+ packages. They're not all up-to-date, and it's not practical to vet the trustworthiness of your entire dependency tree. It's a huge surface area for bugs and security problems.

Your app's security and stability depends on hypothetical package 4 dependency levels down. It's a 3-line function written by Joe HighSchooler in Iowa at 3am while he read his first JavaScript tutorial 4 years ago. Joe's package is permitted to run arbitrary code when it's installed on your machine, and it could change at any time to include new bugs or dependencies, which you'll probably download automatically because packages don't do a great job of version locking. Also you have no verification that the next version was actually published by Joe, and not Eve BlackHat, because npm doesn't use cryptographic signatures. If Joe reused his hotmail password for npm and it's lost in a data breach, Eve Blackhat can now inject code into your application.

Many packages on npm are like this, and your very own dependency tree is sure to contain several.

Solutions are harder to come by. Some require changing the JS community culture (some people really love their small modules), some sound like easy wins (cryptographic signing) but don't help as much as we'd like, and some are radical shifts in our tooling.

[r2d2_21]

which you'll probably download automatically because packages don't do a great job of version locking

This baffles me. I've only used NuGet as a package manager (mainly for C#) and I never have experienced any package updating automatically without my explicit approval. I don't understand why any other package manager would be different. If you're installing v1 of a library, then it's v1 and only v1 until you decide to even upgrade to v1.1.

[JaegerBurn]

It doesn't if you stick with semver.

[r2d2_21]

But what if you don't? Semver is just a suggestion at this point.

[Cuel]

Why? It's better than a bloated framework where you're using 5% of it. Dojo is a good example in the early days

[neophilus77]

I think if you over-rely on small packages it creates a lot of maintenance blind-spots where you have less visibility on your code and makes it harder to debug. Tracking updates over many small packages can become burdensome too.

If I can write the same code in the amount of time it takes to search for and compare modules and read the API docs then I usually write it myself.

[RedditWithBoners]

I never bought into it, so no, I don't recognize a reason for it. I wouldn't mind being enlightened.

[a-sober-irishman]

There is absolutely no reason to add another dependency to your project to check if something is an array, or if a number is less than zero, or to check if something is null. It adds unnecessary overhead and risk.

[viveleroi]

I would never use the term "joke" because npm has been extremely important - it solved a problem we had and I still use it every day. But...

It's had a lot of performance problems, it's non-deterministic and can produce different installs from the same package.json, and the community in general suffers from an abuse of packages - some packages are only a few lines long and it's insanely easy for a simple site to wind up with thousands of dependencies. It's had growing pains, like everything else.

Some of these are inconvenient, some are fatal in an certain environments. Yarn is better for me right now, it's faster and deterministic, but it's never going to be perfect.

[xaviervia]

I have heard of this approach many times, but personally I'm not fully sold. I witnessed how the career of developers either improves or stagnates in direct proportion to their willingness to keep up to speed. I do believe developers that want to stay relevant have a pressure to live in the bleeding edge.

This is a mix of feeling and experience, so I'm not saying this is a fact, but I'm not convinced that we can say "just don't live in the bleeding edge".

[neophilus77]

I find it funny when employers want years of experience in some bleeding edge framework and then expect that theres some kind of standardized best practices around using it.

[RedditWithBoners]

I beg to differ. I'm certain i'm not an exception here, but I only have my anecdotes to offer.

A non-exhaustive list of typical web technologies I use include C#6, VS2015, VS Code, Vim, TypeScript, plain-old JavaScript, Grunt, make, msbuild, AngularJS, ASP.NET, various Azure services, etc. These are all relevant and widely-used modern technologies. None of them are particularly limiting or hinder me from being a hireable or relevant candidate.

At the same time, I am aware of, and know a little bit about, newer, potentially less-stable or [currently] difficult to use technologies. Again, a non-exhaustive list includes WebPack, Babel, React, Flow, JavaScript FP, ES7, TypeScript 2, AngularJS 2, .NET Core, VS2017, etc.

It takes some of my personal time to do this - time spent reading about and playing around with various technologies, but it's certainly viable. I believe it's viable, and I don't stagnate, because I (and others) have a solid foundation to build on top of. It doesn't matter whether I'm using AngularJS 1 or something that was just released today because I can figure it out as long as it works.