JavaScript used to be confined to the browser. But these days, it’s becoming increasingly popular in server-side applications in the form of Node.js. Node.js provides event-driven, non-blocking I/O model that supposedly makes it easy to build scalable network application. In this talk you will learn about the consequences of combining the event-driven programming model with a prototype-based, weakly typed, dynamic language. We will share our perspective as a server-side Java developer who wasn’t entirely happy about JavaScript in the browser, let alone on the server. You will learn how to use Node.js effectively in modern, polyglot applications.
Here is the video of the JAX talk:
plain old objects 
I believe it is time to get past the history of JavaScript and respect the language for what it is and what it is capable of. We need not be hung up on short-comings, we need to look to the future – as you point out. Well done.
Forward-thinking points were brilliant. Such as the “complexity tax”, “no ceremony” and “divergent environments”. Although a simple counter-points would be: first, complexity tax exists everywhere, it is immeasurable, and it is purely subjective. Secondly, while divergence of JS server/client is an intriguing possibility – we are already seeing the opposite in practice: convergence. Specifically, with Isomorphic JavaScript and it is a very intuitive way to homogenize the stack.
Backward-thinking points were disappointing. Complaining about JS as “weakly-typed” is an old stale, and unresolved argument tantamount to beating a dead horse. Simply put, what does this accomplish? A more complicated counter-point to would be – please discover the purpose and advantage that it provides for the web! Often overlooked, under-appreciated, and immeasurable advantages of: flexibility, immediacy, and amateurization. Which are key for general human interaction of the web – not expert interaction, which it sounds like you favor heavily.
In short the jury is still out on Node.JS – we can agree on this – as it is maturing technology. But one thing is clear that it will not be an “abysmal failure” – due to JavaScript being “weakly-typed” and “typo prone”. That complaint is just – hilarious.
Thanks for taking the time to comment.
Let me first address the weak typing (and in more generally dynamic typing) issues. I think far from beating a dead horse it’s an issue that developers have to deal with on a daily basis.
On the one hand there are some interesting benefits: simplicity, not having to deal with a type checker, meta-programming (Grails framework does some really interesting things in this area).
But as I’ve mentioned, I’ve wasted time tracking down bugs caused typos and other issues that would be caught be a compiler in a statically typed language . Not only in JavaScript but also in Groovy. The latter was particularly significant because the code (module A which used module B) was unit tested using mocks. However, because a method signature in B had changed incompatibly (not detected by unit tests) the code failed during integration testing. However, because integration testing involved launching EC2 instances the feedback cycle was extremely long. See http://www.slideshare.net/chris.e.richardson/communityoneeast-09-dynamic-languages-the-next-big-thing-for-the-jvm-or-an-evolutionary-dead-end/30
A larger (philosophical) issue with dynamic/weak typing is that it can lead to non-composability of modules. e.g. two modules set the same property (of some prototype, for example) to a different value. Both modules work in isolation but fail when combined in the same application. Reminds me of http://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure
To summarize, weak/dynamic typing has benefits, and it won’t cause JS to be an abysmal failure. But, there are large parts of many applications that are inherently static. And, its an obstacle to building reliable, composable software.