True, but JavaScript has been in 3D and desktop publishing tools for nearly 8 years. Softimage XSI 1.0 included Js, along VB, python as a scripting solution (when Softimage was under Microsoft's umbrella), Adobe AfterEffects 5.5 also included Js. There were signs during SIGGRAPH 2001 that other tools would follow this trend. Lastly, let's not forget that ActionScript ~=~ JavaScript, scripting Flash was terrible until AS came along.

The same argument about poor quality evidenced by lack of offline adoption could be made for PHP.... JS is a bad language, but not even the best languages see use in all contexts.

It comes down to the standard library. I mean this in two ways. Firstly, I mean that the base methods on the core objects (Array, Date, Math) suck, they suck bad. They suck in a lot of ways because some of them come straight from pretty awful Java APIs. They're not designed for this language, and it shows. Why on earth do you need to use getBlah, and setBlah methods on Date? Or random support in Math: why do I have to first get a double between 0 and 1 and then use that to derive the random number I actually want? Now, tons of the libraries that are used in all your web projects fix a lot of these issues, but many of these also include DOM stuff, and XHR stuff, which a developer has to rip out before they can really use the library on a normal js runtime. Once you've done that, you have to deal with the fact that you're working with a library that's optimized for web development anyway, which is probably not what you're doing. The second thing I mean by the standard library sucking is that, well, actual implementations of libraries to do things like make socket connections, or fetch data over HTTP, or parse XML, or anything like that. At best, you'll be on some kind of shared class space like the JVM or .NET, but that means you have to work with the fact that the APIs you're developing in don't really work in a javascript like way, and you've also got to contend with the fact that the object-bridge may make you work with these objects in special ways. What javascript needs to actually be used in development, is a runtime with developers that focus on developing it for outside the browser, make changes to the language to suit that (since compatability is less of an issue outside the browser) and build up a strong standard library for the development process.

We use JavaScript in the form of Windows Scripting Host for many tools, including our build system (over 2000 lines of code now) - since 2001.

From what I've read, Google is using JavaScript (Rhino) on their servers (search for "google rhino").

I would take JavaScript seriously if it weren't for the fact that users can just turn it off, and increasingly are doing so. If 5% of my users could disable sites with PHP, do you think I'd use it for anything but trivial presentation (which is what I use JS for)? As a web designer, I make sure all my sites work in IE6, IE7, Firefox, Opera, and Safari (which covers Konqueror too). Semantic markup makes them work on mobile devices and in Lynx too. Why do I do this? Because the businesses who are my clients aren't paying me to exclude potential customers.

What idiot said Javascript was a great language? One that'd actually used it and knew it.

JS for shell scripting suffers from a lack of good libraries for file manipulation or other standard unix shell utilities. Otherwise it would be great to not have to require another language for developers to use.

JavaScript is a great language. It's simple and powerful at the same time. It does need more libraries but that would be true of any language that's just coming into it's own after being pigeonholed in a browser environment for so long. I think Jaxer was mentioned above and there's also the new Axiom Stack. When platforms like this take off, there will be more library support.

How about server-side Javascript ala Apatana Jaxer? Comes with some file IO libs (even rudimentary DB access option I believe).