In an article written for publication on TheServerSide, Alex Craciun writes:

After reading the “ JavaScript: Unscientifically tested to be more annoying and frustrating than Java” article, I realized that others may share my feelings about Javascript, not about the language itself, but rather about matters when dealing with it inside an enterprise like development cost, productivity, maintainability, quality. 

Again unscientifically, a Javascript line of code seems more expensive (a factor of 2-3) than the Java equivalent. It seems to me that the Javascript part of the project we build always takes longer. One explanation can be linked to the relative knowledge about the two languages of the developers I work with.

I had this discussion with a guy the other day; he mentioned that he doesn’t understand why he sees lots of job opportunities for Java/.Net specialists, but never for Javascript specialist. My explanation to this is that, unless you’re node.js adept, Javascript alone cannot be used to build completely an application. It’s always a language that is complementary in a project that is mainly written in Java, PHP, .net, Ruby or other language. 

In the full article, you seem to call out the dynamic nature of Javascript as the main issue.  The thing is that Ruby and PHP and 'other' languages are also dynamically typed.

I think this indicates that there is more to the challenges around Javascript than just dynamic typing.

Personally, I find that because many things in Javascript fail silently, it's easy to ignore issues or at least not realize they are issues until later.  Additionally, because Javascript executes in the browser, there are platform support issues.  When I run my java web server, I only have to worry about one OS, one JVM, and one application server.

I also feel that the usage of JS has and continues to evolve and we have passed from using Javascript as a cool add on for web application development to a critical part of it. So should the best practices of Javascript developers evolve. There is more and more JS code in webapps written by bigger and bigger teams of developers. Many JS developers create quick and dirty solutions almost as if they were just throw away prototypes and they end up being included and (painfully) maintained and evolved during the rest of the life of the webapp. I've also seen that there are multiple "styles" of wrighting javascript code which when mixed add to the confusion.

I have nothing agains JS itslef, it's a very powerful language, but JS programming has to be adapted depending on the type of project it's being used on. For small, one person, personal projects do as you wish, but once you are part of a bigger team, the team would benefit from agreeing on an adequate set of best practices... And one day there will be a more stable standard set of best practices... I wonder if JS development will be still as interesting though...

You are both true, in fact.

There is not a single reason why Javascript (or PHP in a lesser extent) is an issue in the context of most entreprises.

There are lots of reasons: lack of langage formal structure (dynamic types...) leading to longer refactorings and code-writings, lack of exploitation tools that are an issue for quality managers, difficulties about debugging that increase the maintenance costs, instability due to external factors like browsers versions and upgrades... and so on.

All those problems can be solved by having top experts under the hand that know perfectly how use the langage, but the problem about this solution is not everyone is Google or Facebook  and can afford to have 80% of experts in their programming staff. To start with, there is not enough real experts around the word for all entreprises, so only the ones with the biggest wallet can rely on a such staff.

For all the mid-sized and low-sized enterprises, there is a real need to be able to make working and reliable applications with only the help of average developpers or even sometimes a bunch of begginners helped by a single expert.

That is not possible with a langage that let those developpers write things as stupid as "this variable meant to be a numbre recieve the value of this variable meant to be a character chain without even checking it represent a number and provide a fail-over strategy if not". The expert of the team would have to review VERY SINGLE LINE of the code to ensure it is well-writed and won't lead the application straight into a wall in a few days, weeks or months... at this rate, the expert would be faster to work alone and write everything by himself. (Post author's point about dynamic types)

But that is not possible also with a langage that requiers extra and expert coding to ensure that when the application crash due to a bug, it provides enough information to make the repair process faster. Once again, it'll mean that you need experts to write most of the code.  (Your point)

And there is much more reasons to come, as I pointed out, that makes that a langage which was not thought from the start to be used by enterprises, as Java and .Net are, is a real problem for enterprises that can't afford to have only experts in their teams by need reliable applications to run their business.

That is only possible with:

- a paranoiac langage that try to check everything it can, just kick the developper on their rails at every doubtful line of code, force them to be extremely precise of what they want to make and how they want the exceptionnal situations to be handled before deployment...

- a langage that do the most possible to always provide as much information it can when a failure happens post deployment, even if the developper didn't think about any fail-over mechanism that will report anything about the circumstances of the failure...

- a langage that do not requiers to know the specific of 40 versions of browsers to write code block that will work everytime.

- a langage that comes natively with tools that don't requiere a top expert to handle the complexity of basic entreprise needs: internationalization, load balancing, migration, basic documentation, monitoring... and so one.

"How much expensive is a line of JavaScript code?" the author asked.

My answer: for all entreprises except the richests that can afford experts for everything, in terms of cost for quality insurance and maintenance, A LOT more than a Java/.Net one.

Yes there are several problems that make the life of today’s web developers and project manager quite complicated. Development costs seem quite difficult to control; maintenance and evolution even tougher! jQuery, Dojo, Prototype, Mootools seems to address quite well the browser incompatibility issues.

I agree with James and you that the dynamic typing of Javascript seems more troubling to me. As many others, we looked into available solutions to stay on the strongly-typed side of the languages spectrum: GWT, Vaadin, JSF, etc.

But as I wrote in a previous article  these solutions seemed too complicated for what we needed. Our answer (at least until we find better!) to this dilemma is our open source project - Strongly-typed Javascript. As this is a young project, it’s too early to say we no longer need to hire top 10% web developers in the world to build and maintain a decent web site at a decent cost ...

Even if every professionnal programming expert knows about the trouble that a lack of typing can bring to maintenance of an application, it is just the most "visible part of the iceberg".

Javascript (and PHP in a lesser degree) has lots of other issue and use a project the enforce strong-typing isn't enough.

First, because half of the gains of strong-typing is IDE helpers that make average developpers gains lots of time during coding phase by auto-completion and semantics auto-checks. IDE helpers that are totaly deficient in Javascript even if you introduce a third-party framework to force the strong-typing of your variables.

Second, because it doesn't solve all the other problems, like the need for experts or for a community work (like jQuery as you pointed out, but you can't do everything with the few JS framework that are stable enough to be reliable) to reach a quality of code that can reliably run on "every" browser... like the fact that in two months, Microsoft is going to release another bugged release of their JS execution engine and that you will be needed to review a perfectly working code once again because it needs to work correctly on the new Internet Explorer too (not I don't say it can't happen with Firefox or Chrome, it just happen less often for them)... like the need to deal with basic concerns like internationalisation, security, monitoring, correct binary to decimal float transcoding, evolutivity, reusability, scaling, reporting...

I'll put it simple: JS is going better from year to year. But at the current pace, it's ten years too soon for it to reach a state of industrialization of programming as Java or .Net currently have and the average enterprise isn't going to capitalize on a langage for what it could become in ten years.

They have needs today. So it makes sense that IT decision-makers choose a programming langage that brings the most quality for the less money as the main programming langage for their custom applications... and so it explains why there is so many offers for Java/.Net experts jobs and so few for JS expert jobs.

Unfortunately there are not many ways to protect your code againts futures problems that may appear in new browser versions. For this, the only solution I can see is to have unit and integration tests to be run on the available browsers.

The framework we propose is basically a generator from Java to Javascript, so you write your client code in Java taking advantage of all the features it's coming with (unfortunately also, at least until Java 8 is out, having to deal with the lack of closures and lambda expressions).

Of course it would be simpler to just run your Java directly on the browser instead of passing through Javascript (I know applets exist, but that's maybe not the best way to develop webapps :). This supposes of course to have to compile your code before publishing it ...  that is rather unusual for many web developers nowadays.

Your framework do the same than GWT, but I didn't find this strategy to be a reliable solution to the problems either.

It just adds another abstraction layer between your developement code and the source of the problem, which perhaps make the problems happens less often since the framework's authors make a part of the technological survey for you, but make them worst to solve when they do: then, you have to dwell into a compilation logic you don't own nor master to understand what is going wrong or wait for the authors to fix it... which will happen you don't know when, which is not an acceptable answer to the enterprise maintenance needs (ever try to say to an angry user facing a severe bug "I don't know how it will be solved because it is not my code I've inserted into the application you paid me to develop?"... that's lots of "fun", I garantee you)

And for unit tests.... they are a source of development and maintenance cost too, so it doesn't really solve the problem, just make it happen elsewhere: you pay less in maintenance to solve bugs, but you pay even more development and maintenance to build and keep lots of unit tests up to date.