Are you serious? The author says:

"Real developers have a strong aversion to Javascript, and for good reason. It's a twitchy, skittish scripting language that is made even harder to work with by different browsers processing Javascript in subtly different ways. Javascript was never intended for the design and maintenance of robust and sophisticated software applications."

1. Real Programmers? Real programmers are capable of mastering whatever tools are required to get the job done.

2. Twitchy and skitish? I have never heard a programming language characterized as "twitchy and skitish". In fact, I am not even sure what those terms mean in the context of a programming language.

3. Who have you been talking to that has the background to make the assertion regarding what Javascript was intended for, and how is that even relevent? For years software developers have been successfully extending technologies for purposes beyond the scope of the technology's original intent.

Trackback Added: Riding the hockey stick: Scaling Web 2.0 software; With all the talk last week about MySpace becoming the #1 most visited site on the Web, there's also been a lot of talk about how Web 2.0 sites like MySpace handle their sharp growth rates. Because Web 2.0 sites explicitly leverage network effects, wh...

My friends insisted that I give my reasons why do I think Java to Java Script is not such a good idea. I guess it is a fair demand. Without getting into the details of the specific product (GWT), here is a list of my reasons:

1. There are many open questions - what packages of Java can I use, will collection classes map onto JavaScript code, can I use Java timer, can I use Java multi-threading?

2. How primitive types are handled?

3. If the generated code is not optimal, can I change it? (remember all the pains of changing generated code in any code generation model)

4. If I have to change the code generation template, is it worth it? "I can change it" - it is not a valid argument. It often requires heavy duty work to change and mantain it.

5. Can I avoid learning HTML DOM? If yes, then what is the UI model? Do I have to learn it?

6. Java provides compile time checking. But I may need a dynamic programming model (which is good for UI. There is always some display only information that you need to handle without worrying too much about its data-type).

7. Is it proven for a production application?

8. Can you really escape JavaScript if you have chosen AJAX as the technology? Or, do you really want to escape. Very soon you will need to know JavaScript say, to improve performance.

9. I find development cycle (code change, execute, test) is very efficient for an interpretive language.

10. If we had a good JavaScript debugger, would we be thinking about Java to JavaScript. If not then, is it not an interim arrangement?

I like to be a contrarian and call it a brain dead idea. We need a JavaScript debugger and not a Java to JavaScript compiler. It is all about DOM and not so much about JavaScript. It will be a nightmare to debug if Java to JavaScript has one wrong mapping.

It is a radical idea though.

I tip my hat if gmail and google map were really written using Java to JavaScript way.

"Surprisingly, developing GWT-friendly services will NOT create an open, interoperable Web service"

I'm sorry but I don't see this as a problem. The GWT is targeted at building rich-functionality user interfaces in the browser, so the server-side interface to support the dynamic nature of the application will by its nature be tightly coupled to the precise requirements of the widgets it is supporting. Those widgets can and will change, and so will the server-side interface with them, even if the underlying business process does not.

It is logical to share business services but the server-side interface of an Ajax-enabled browser application is not a set of business services but a set of internal user interface support services. Don't confuse the two!

Google's recent foray into delivering an Ajaxified Web application stack, the Google Web Toolkit, says much about Google's pragmatic method of delivering innovation to the market. I for one, would heartily recommend it for certain applications, while actively advising against it for others. One major issue is that Google makes a lot of assumptions in GWT that are non-starters for certain uses.

Google's recent foray into delivering an Ajaxified Web application stack, the Google Web Toolkit, says much about Google's pragmatic method of delivering innovation to the market. I for one, would heartily recommend it for certain applications, while actively advising against it for others. One major issue is that Google makes a lot of assumptions in GWT that are non-starters for certain uses.

Google's recent foray into delivering an Ajaxified Web application stack, the Google Web Toolkit, says much about Google's pragmatic method of delivering innovation to the market. I for one, would heartily recommend it for certain applications, while actively advising against it for others. One major issue is that Google makes a lot of assumptions in GWT that are non-starters for certain uses.