Today it’s Node. Before it was Rails. Before it was PHP. Before it was Java. Cogs Bad:
There’s a whole mindset – a modern movement – that solves things in terms of working out how to link together a constellation of different utility components like noSQL databases, frontends, load balancers, various scripts and glue and so on. Its not that one tool fits all; its that they want to use all the shiny new tools. And this is held up as good architecture! Good separation. Good scaling.
I’ve fallen victim to this mindset. Make everything a Rails app, solve all the problems with Ruby, store all the data in distributed databases! It’s not that any of these technologies are wrong it’s just they might not yet be right for the problem at hand.
You can almost age generations of programmers like tree rings. I’m of the PHP/Rails generation, though I started in the Linux generation. A few years ago, I thought I could school the Java generations. But it turns out, I’ve learned a ton from them, even when I was a bit of a hubristic brat. The Node generation of developers will teach me more still, both in finding new virtuous paths and in going down false paths so I don’t have to follow them.
That said, it would be delightful if there was a shortcut to get these new generations past the “re-invent all the things!” phase and straight into the “make useful things and constructive dialog about how they’re better” phase.
Adam Keys is typing 
Another take on the silver bullet mindset is purposeful ecosystem reinvention. I once heard Mikeal Rogers, a Node.js core contributor, give a talk contending that in order to build the future of web applications, it’s imperative to own not only the client- and server-side, but also the transport. This of course, is a daunting task, not being able to rely on beloved and battle-tested nginxes, haproxies and varnishes of today.
As for the reason why load balancing and session handling are best handled through Node and not something like haproxy and nginx, I’m not entirely sure. I think it has to do with persistent connections or websockets, which may not be fully supported, realized or first-class citizens within existing components.
You’re definitely right about one thing: the sooner we eliminate programmer hubris, the less time we’ll spend reinventing and spinning wheels.
Varnish in particular is a good example. How do you know when you’re making Varnish or nginx and not just rage-rewriting Squid or Apache? My best guess is if the principles you’ve set for yourself make sense to someone outside of your community. If your principles wouldn’t stand to that test, maybe it’s just an interesting weekend project.