Just look here and then there. As I read the first, I knew from the headline that there will be the second.

First of all JavaScript is a powerful language, if you still think it is a small language to animate some icons, look what Douglas Crockford has to say on it (http://javascript.crockford.com/javascript.html); even if you are a hardcore programmer you’ll have to admitt that it is damned powerful.

What it makes it also important is that that it is ubiquitous. All browser implement it out of the box and there are less security concerns than with any other language on the browser platform.

But it is also a horrible language. One half of the story is the platform. There isn’t just browser, there are at least four (IE,Mozilla,Opera,Safari). They are similar, but far from being equal. They remind me of the subtle difference between various UNIXes I dealt with 10 years ago (we had to support  8 UNIX and all “tar” commands behaved differently). The browser is the OS for the web-clients (I say clients here, on the server side it is not better if not even worse). For any mid-scale use (=your are neither Google nor your programming your homepage) you have to use some toolkit to harness  the power of JavaScript and DHTML. Java main strength is that the platform is virtually no problem, modern C++ use relies on libraries (toolkits in newspeak) to achieve the same.
This is part of the reason why there are so many libraries and generators like (GWT and ZK). The other part is managability of the code; it boils down to the same battle as between Java and Ruby. As JavaScript is (ironically) as expressive as Ruby, it shares the same problems. Both language allow to make marvelous thing with little code, but the problem to manage several 100kloc* written by large, distributed teams over years is either not proven to be solvable (in case of Ruby) or proven to be unsolvable (in case of JavaScript). This is for sure too general, but for average-quality projects not too far off.

I am not talking about Ruby here (a well-designed language BTW), but JavaScript has some serious issues:

• There are some flaws in the spec (what is “this”)
• encapsulation asks for a horrible syntax
• versioning on the “deployment”
• IDE-support is poor, thus
• limited refactoring
• debugging

This limits productivity as soon as the complexity grows beyond a small team. This means that it is well possible to have high-quality toolkits or to use (like GWT) JavaScript like advanced bytecode, but projects like Phobos can get you into trouble even if you start off well. If you know you will perhaps never reach the complexity where the know issue become a problem - and I think 80% of all projects never do - the issues are managable or non-existant. For the other 20% (large enterprise applications) that pay 80% of the salaries,  I find it too risky or frankly - from 1st-hand experience - “inappropiate”.

*On complexity: If a language promises that you can do something with a tenth of the code you’d need in language X; this might be right. But don’t expect that this resolves your complextity problems. Most problems complexity is not linear like the code reduction you might get (let’s leave out the inherent complexity); it is quadratic or exponential at worst. A better (=more appropiate for your problem) language will only buy you (at best) some time. You have to work on the problem to survive in the long run and you have to use tools, so a well “toolable” language (and Java is perhaps best in this category, at least in respect of existing tools, for example Jackpot) can easily overcompensate a bit verbosity.