As long as I'm airing all my misconceptions about JavaScript, I might as well include another one. Up until recently, I thought that JavaScript had some special relationship with the browser -- that JavaScript was the browser's toy language and nothing more. And there are good reasons why I would think this. After all, if you pop into your local bookstore and buy a book on JavaScript, it will likely spend the whole book focused on web development. Similarly, if you read forums or articles about JavaScript on the internet, no one bothers to clarify that they are talking about JavaScript in the context of a browser; it is simply assumed.
Despite this, I was aware that there were a few open source JavaScript engines. For example both Firefox's SpiderMonkey engine, and Chrome's new V8 engine are both freely available. I had also heard of the Rhino project, a JavaScript implementation for Java. But I still thought that these were just for people who wanted to make their own browsers. After all, who would want to use JavaScript outside the browser? Doesn't JavaScript need it?
Well, as it turns out the answer is yes...and no. I had made the same mistake that it seems many other make as well. JavaScript is actually quite a plain scripting language, providing only the most basic standard libraries (Math functions, Array functions, etc). Generally speaking, instead of focusing on the language itself, most books focus their attention on using JavaScript to manipulate the browser's Document Object Model (DOM). The part that I had missed is that the DOM object is provided by the browser, not by JavaScript. The misconception must be strong enough that Google felt it needed to clarify it on V8's introduction page :
JavaScript is most commonly used for client-side scripting in a browser, being used to manipulate Document Object Model (DOM) objects for example. The DOM is not, however, typically provided by the JavaScript engine but instead by a browser. The same is true of V8—Google Chrome provides the DOM.
Also, from the Wikipedia article on JavaScript :
JavaScript typically relies on a run-time environment (e.g. in a web browser) to provide objects and methods by which scripts can interact with "the outside world". (This is not a language feature per se, but it is common in most JavaScript implementations.)
Let's liken a programming language to a spoken language; how to the various parts map? A programming language's syntax, data structures, idioms, design patterns, and core concepts would be similar to a spoken language's grammar rules. A programming language's standard (and available) libraries are similar to a spoken language's vocabulary. A language definition +can +exist without a vocabulary, it's just not all that useful. This is exactly where JavaScript fits. JavaScript is a full language, but without help it only knows how to speak the basics words of Objects, Arrays, and Math. To be useful, it needs an external program to teach it new vocabulary. In the browser's case, it teaches it the vocabulary of the DOM, creating a dialect I will call DOMian.
Even though DOMian is only one dialect of JavaScipt, it has become so synonymous with the language that I thought that the rules of DOMian were actually rules of the language. After all, every book on JavaScript immediately launches into the DOMian dialect. Why would I assume that anything else existed? But it turns out there are lots of people who have taught it different vocabularies. For example, the programmers of Sphere have taught it RPGian, the vocabulary of role-playing game design.
Without help, JavaScript lacks any vocabulary for interacting with the outside world. By comparison languages such as Python and Perl have rich vocabularies to discuss I/O, threading, and networking with ease. They don't need (but still allow) anyone to teach them new vocabulary since they can already do so much on their own.
However, I actually think it is JavaScript's lack of vocabulary that makes it an ideal scripting language to embed in a project. While other languages such as Python are also easily embeddable, they often are too knowledgeable for the task. After all, in an embedded context, you probably don't want Python spawning threads or doing lots of I/O without the extended-program's approval. You can solve this problem by limiting Python's vocabulary (removing standard libraries). The problem with this is that people who are used to speaking Python get used to these constructs, and get frustrated when they aren't there. By contrast, since JavaScript has almost no standard vocabulary, you can much more easily embed it and teach it a new dialect without having to censor its speech in other areas.
The flip-side is that this makes JavaScript a poor choice for doing traditional scripted tasks. Instead, this is where Python's (or Perl's, or Ruby's) rich, expressive vocabularies really shine by helping you do more in less time. The key is learning a language's strengths and weaknesses so you know when the rich vocabulary is good and when it's not.
"A language for everything, and everything in its language"
