Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.

Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.

The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well.

In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.

We've been using npm 3 on multiple large projects spanning frontend and backend, being worked on by many developers, pushing code through CI into production many times a day and npm installing fresh in every environment. There are probably many thousands of nested dependencies in some projects. It works, nothing bad happens, it's fine.

Npm comes with some trade offs, true, but also a long list of plus points as well. No system is perfect, but you're painting some calamitous disastrous picture here which simply isn't reflected in reality.

In particular, I envy whatever combination of dependencies and development platforms you get to work with, because I haven't seen a single project with no problems due to updates since NPM3 arrived, never mind all of them. (Edit: This is not intended to imply NPM3 is the only reason for the problems, only to define a comparable time frame.)

Even if you're in an environment where shrinkwrap is working well, we seem to find transitive dependencies of installed packages that introduce bugs or break something without correctly updated semver with alarming frequency. As some of us were discussing here on HN the other day, this has happened so often with Gulp plugins over the past few months that one project I work on dumped the entire Gulp ecosystem (and instantly and dramatically improved developer productivity as a direct result).

I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs, some of them due to dependencies breaking, but nothing calamitous or actually bad, and nothing out of the ordinary compared to other stacks and tools imo.

Npm module churn can be annoying sure, but on the flip side its good to be getting incremental patch updates sometimes too. And with exact versions in package.json and shrinkwrap you can eliminate enough uncertainty that to all intents and purposes its really not a problem.

> dumped the entire Gulp ecosystem

Amen to that. Gulp plugin eco-system has been messed up for a year or more. We do all our frontend builds with npm scripts now, running the bare cli tools where possible, and reducing dependencies as much as possible (e.g. Gulp and all its plugins).

It sounds like we do have a similar philosophy as far as tooling goes: simple scripts, minimal dependencies. But I add to that a strong preference for tools like build systems and package managers and source control systems to have completely deterministic behaviour and therefore provide reproducible results by default.

In practice, trusting semver has caused real world problems for some projects I've worked on with non-dev dependencies too. For example, a few weeks ago, Facebook pushed a bad update to React that completely broke dev builds on IE. It was fixed a few days later, but during that window NPM considered the broken version just as good as the version we'd been developing and testing with for the past couple of weeks. Tracking that one down wasted a few hours in our office as we tried to figure out why tests were failing on our new build/CI machine but whenever the developers tried it everything seemed to be working fine.

I guess I just don't understand the decision to make ambiguity the default with NPM, particularly with the Node/NPM culture of using very many small dependencies. It's not as if it's difficult to issue a message if a newer version of something relevant is available, or to provide a command or option to deliberately change to newer versions of packages -- pretty much every package manager in every language I've ever used does these things -- so introducing unnecessary variability just seems like asking for trouble.

Relax. You're talking about someone's opinion of a programming language.

That said, all of your comments come across as ignorant to me. I don't think you're ignorant, though. I think you know JavaScript really well and like it.

I personally found it unusable on the server until TypeScript became mature enough to use. Have you tried TypeScript or some other static-typed, better-defined language (Flow, Clojure, etc.)?

You may love JavaScript, but there's a good reason Facebook, Google, and Microsoft all find it to be unusable and have created compile-to-JavaScript languages so that their companies can be JavaScript-free someday.

We use Typed Clojure where I work. To say it's because we "don't want to write Clojure by hand anymore" would be nonsense.

Reading your comments in this thread, I think you'll find out one day that people just have different appetites for different trade-offs and that's really all there is to it. No need to wheedle, condescend, or link Paul Graham essays.

The good news is that a lot of programming skills are fungible, and you (like me) will eventually use things you like more than you expected -- perhaps even more than you like JavaScript. The time you invested won't be wasted.

1. http://www.paulgraham.com/avg.html

And if we're talking about emotional investment in technology ... I think that's where most of the JS shaming comments we're seeing on this thread are coming from. People feel a bit threatened by it because it seems like it's eating a lot of things at the moment. They'd be better off following your advice and stop sniping at it and take an interest.

I'm anthropomorphizing Javascript somewhat here, attributing the feelings of its community to the language itself. But from the point of view of someone whose first programming language was not Javascript, the trend is pretty apparent: We can run Javascript anywhere, so we will run it everywhere.

The only thing that's happening here is that a community has formed around an evolving language and is taking advantage of some great tooling and open source projects to do some interesting stuff. That community isn't formed exclusively of wet-behind-the-ears web developers. It's comprised of developers of all skills levels with experience in a multitude of platforms and languages, just like any other. These people chose JS because it works for them and their problem set. To suggest otherwise is condescending to say the least. Stop trying to paint the whole community with a single brush, you sound ridiculous. If JS isn't your bag fine, move on, but less of the JS shaming please.

They're building operating systems with it now.

See, NodeOS and Runtime.js.

The "Birth and death of Javascript" talk is beginning to look less like satire, and more like moderately accurate prediction.

I'll give you the passionate community point. I almost completely disagree with everything else.

JavaScript is a very immature platform.

JavaScript has probably the worst packaging ecosystem of any major programming language. The fine-grained packages, indirect dependencies, and frequently broken versioning cause endless problems in real world systems. Recent attempts to fix the package manager have unfortunately swapped one set of problems for another, while still leaving some of those fundamental weaknesses involving transitive dependencies and excessive trust of version numbering conventions unaddressed.

It does has rapidly evolving syntax and semantics, but at the expense of stability, portability and future-proofing. The only reason 99% of JS programmers use most of the new syntax and semantics is a combination of a transpilation tool written primarily by one (remarkable) person and a polyfill written primarily by one other (remarkable) person in their free time. Browser, tool and Node support for many of those new features is patchy, which is why that transpilation and polyfilling is necessary.

Tooling for JS is at least two decades behind the industry best-in-class. It's a dynamic language that now has such a huge mess of build tools associated with it that seasoned veterans of web development weep at the prospect. You can't reliably debug real world JS code in its natural form, even on the level of setting break points and examining local variables and call stacks, without jumping through all kinds of hoops, and in some browsers even then. Profiling also relies almost entirely on browser magic. There are lots of testing tools, but setting them up is often a chore and they have widely varying degrees of power and flexibility. We've only recently got a style checking tool that can actually cope with ES2015 reasonably well. Refactoring, auto-completion, documentation, navigation in your editor? What are those?

As for Node... I've seen experienced developers spend months trying to get basic stuff working in a cross-platform way with Node, and then seen other experienced developers do more in a week or even a day using C. Using Node is saying "I know, let's throw out a few decades of experience building reliable client-server systems and all the other tried and tested languages and tools and libraries we've developed over that time, and instead transfer all of those negative aspects of JS to the server side as well, even though unlike front-end developers we don't have to".