Javascript - Game changer or Distractor?

This started off as a response to a comment made by Sarah in response to a comment made by me on her blog. I started getting carried away so I thought instead I'd throw it up here and share it with the rest of the world, for what its worth.
In my opinion, javascript and its associated technologies has the potential to completely redefine whatever notions we have of the web.
Before returning to teaching I was a developer for the past 20 years and the last 8 years have seen me fooling around with web development. 
I'm either lazy or dumb or both but I like simple things - easy to grasp and easy to implement so I have gravitated towards less computationally onerous frameworks to render web applications. 
Like Apache Cocoon and XML and XSL. 
Cocoon especially has evolved into more of a Java heavy framework and seems to be retreating from its XML pipeline style of processing and is starting to give me headaches.
The XSL spec has a new version that I'm totally unfamiliar with but is a huge improvement on version 1 (which was wonderful and extremely powerful in itself) but has lost a bit of traction particularly in browser support. 


This brings me to javascript.


What does it do and how does it do it?
Javascript (developed by Brendon Eich of Netscape) is still primarily a browser based language originally intended to enhance the user interface and add a bit of zip to the user experience (alert boxes, mouse rollovers etc). 
Some clever individuals started using javascript to modify the browser's DOM (document object model) in real time instead of waiting for a web page to be refreshed or modified via a round trip to the server. 
This technique became known as 'AJAX' (asynchronous javascript and xml - a term coined by Jesse James Garrett in 2005). As a background, check out the Discussion tab on this wikipedia article.
Since then, javascript has emerged as more of a central programming interface that makes web pages behave and look more like desktop pages.
Think Google Maps and Gmail and, yes, Blogger. 


It kind of works like this:
Instead of requesting a complete page refresh (with new information added) by going to the server and having the new page constructed by a process running on the server (written in a language like PHP or Java or ASP), the web page makes an asynchronous call to the server process but only updates the required section of the local page (usually a <div>) with the new information.
The updated information is usually sent back as an xml document and converted on the browser into valid HTML and then inserted into the uniquely identified element in the document. More recently, programmers are using JSON (javascript object notation - devised by Douglas Crockford) which is faster to evaluate than XML and improves the performance of the whole round trip.
The result is a faster, more dynamic user experience that results in almost desktop application user interfaces and response times. The client to server lag is reduced as less data is being transmitted.
To this end, a lot of developers that used to view javascript as a bit of a 'toy' are now realising that the language has enormous potential.

Rapid advances in browser technology have seen further developments in web standards: HTML5, WebGL, H.264 video etc, which all contribute to the rise in web based applications. Browsers now have the capability of making calls directly to the computer's GPU (graphics processing unit) to speed up screen refreshes and updates.
The argument used to be that web based applications were fine but they would never replace Photoshop - that is now starting to change.
Check out Chrome Experiments. The web world is being turned on its head.


Where does this leave javascript as a 'back end' (server based) language? 
I'm glad you asked.
The server is where all the heavy lifting takes place. 
CRUD manipulation of a database (Create, Replace, Update, Delete). Security checks. All the behind the scenes stuff that web users don't get to see or appreciate :( .
Developers have complained that they need to know a back end language really well (like the aforementioned PHP, Java, Python, Perl, or ASP) and whereas they only needed a small amount of javascript knowledge and ability.
Nowadays the javascript takes more prominence and as such every developer worth his salt needs an indepth knowledge of at least 2 languages. 


Enter SSJS (Server Side Javascript).
Boffins have been toying with the idea of server side javascript for some years - Mozilla Rhino and Aptana Jaxer are two cases in point. These solutions appeared to be a bit cumbersome - Rhino is an implementation of javascript written in Java and doesn't appeal to non-java afficionados and Aptana seems to have dropped support of their Jaxer server product altogether.
But, when all seemed lost, in 2009 Ryan Dahl introduced Node.js to the world. 
Node.js (known as 'node') allows for the creation of server based javascript modules that can be called from a browser. Since its introduction it has gained a lot of traction in the web development world. Now developers can concentrate on one language only to satisfy both their browser and server based requirements. 
Coupled with the acceptance of HTML5, the <canvas> element and WebGL, javascript promises to be the one language that will unite both ends of the web development spectrum.