As someone who has used both, I have to give this battle to Node.js and Socket.io. The ease of use because of the common client/server code almost blurs the line between the client and server and makes it almost a pleasure to use. Whereas in Play/Scala, there isn't a libary I can use for both the client and server, thus I either have to write my own client library (or use one) and then write my server code. From a maintainability standpoint, Node, in this particular use case, just demolishes Scala/Play.
Your main point appears to be sharing code on the client and server side. Scala.js has reached 0.1 and is quite decent [1]. Personally, the only code I find worth sharing is validation code and template rendering code. As for "maintainability", I find it is much lower in node.js and JS projects in general. Each has its own structure and is scary to refactor (unless you're a TypeScripter or something). I don't believe it's fair to use those two points to say it "demolishes" Scala/Play. Also, some webapps do real work per request (not just routing IO), and even though it is very quick (i.e. not worth farming out to a resque-like job engine or a web-worker in node), the fact that it blocks the node process scares me as well.
I think it's a bit over the top to compare Scala to JavaScript and node.js.
If you're comparing the two you have way more flexibility than you should because these are two widely divergent tools with different implications reaching beyond "easier" or "faster." I don't think people ought to even consider scala if they're considering "easy" as being a significant factor.
Scala enjoys type safety and compilation and a vast and deep sophisticated feature set, not the very least of which is inherited from the proven and storied java libraries. Node.js is a mess of shit heaped on the turd that is script-kiddy npm-land covered with int-less and unicode unsafe JavaScript.
This is such an odd argument. As a developer that likes to produce usable products, 'easy' is something I'm always looking for. Why not? Just because something is 'easy' doesn't mean it's inadequate. It all depends on what you're building.
Also, your misguided rant against node and npm rather hurts your credibility. Your argument was at least ok up until that point.
Pretty sure dependencies can come straight from a git url, bypassing npm. Put something on npm, and in your package.json you can depend on something straight up from github. npm will install and build that and it may break your stuff, it's a gamble. Given how dependencies nest into a massive web, you don't have to use many things before you end up with something that breaks you.
shrinkwrap just locks down a version of a dependency, if the dependency points to a git master branch, that's not locked down. shrinkwrap doesn't install any code. I think his point is valid, although also probably still very rare.
