Having dependencies is not bad. But slapping a system together with a ton of dependencies you don't know about is bad.

Simple is better in my opinion.

Simple isn't always better. Reusable patterns are. WhatsApp followed pretty standard erlang design patterns.

Rails and Django to some extent force a standard pattern, they're not really low dependency systems(although they are compared to most node projects). But that pattern to some extent makes sure that you can hand over the project to the next dev and he'll be able to make sense of it.

Somehow node.js has become what PHP used to be.

Whatever happened to interoperability? How are there hundreds of queuing system that use redis and rabbitmq under the hood, but you can only process things in python, javascript or ruby? The data structures are considered private.

So if you want to process your code in python you have to use the python message queue, if you want to process it in javascript you have to find a node mq. How does that make sense?

Want to do business intelligence on your javascript based system now? Gotta write javascript code. Welcome to debugging the same kind of memory leak and processing issues every other queuing system has had to go through.

I agree, but this assumes you actually know what you are building. This isn't usually the case for a startup.

I'm sure whatsapp wanted a million users, but they didn't originally know that would happen. If whatsapp later turned out to be about serving fewer users with more features, this becomes a story about premature optimization.

> with thousands of users bug-testing it for me

Replace this with:

> with thousands of users just like me that once picked it as a dependency and then forgot about the project