I have always thought of JavaScript as a client-side scripting tool for augmenting the functionality of HTML, which in turn is usually generated by some other server-side technology - Java, .NET, Rails, Django, PHP, etc.
Recently though I have heard people talk about JavaScript as an "application language". I understand that applications like Gmail have taken JavaScript to the next stage of evolution and have made the browser much more like a full-featured application. But as far as I know, there are no server-side technologies like the ones I mentioned earlier that are JavaScript based. So even in the case of a Rich Internet Application, the "application language" is really the one on the backend that interacts with the database and performs URL routing, etc.
Is my understanding outdated and is JavaScript now capable of performing backend processing or are we willing to call it an "application language" simply because its current sophistication in what it can perform on the front-end is such that the backend processing has become secondary?
Serverside Javascript has been possible for a long time now. I maintain code with it every day. It's way better than classic ASP (at least I can have "real" objects, and try-catch, etc).
Another great thing is that you can avoid recoding your form validation code in different languages. I just use a javascript file like this:
<!--//<%
//code
//%>-->
That allows you to both include code with <!--#include file='name'--> and with <script src='name' />. On the downside it could be lot easier to "break" your validation code by looking at it (if you weren't careful enough). Never put sensitive information in there outside the validation code. Also, you can choose the file extension that you want, but never save serverside javascript that does database access as .js. .asp files are by default executed and not sent as plain text. That is not true for .js files, which are only executed if they are included in an .asp file.