During my three days at TSSJS talking about the issues of client-side web development, one theme was repeated several times. There was this undercurrent of the group trying to decide the appropriate role of JavaScript in a web application development environment. As the presenter of "Modern JavaScript Programming", careful readers will already know what my position is.

There were three camps in the discussion:

• those who write JavaScript by hand
• those whose framework controls the JavaScript, but it is still stored and maintained as raw JavaScript prior to being shipped to the client
• those whose framework creates JavaScript from another source

The first camp was made up of adherents of one of the many Ajax libraries out there, or their own "craptacular framework" as one of my fellow panelists put it. The second camp could be called the JSF camp, though Tapestry and Wickets and others fit here as well. The last is made up of the GWT people.

I heard this one phrase several times: "since framework X let's me not worry about all that JavaScript mess…" The discussion turned several times to how GWT let's you write your code in a decent language (Java) and pretend that the JavaScript just isn't there. The phrase "compiling to JavaScript" was thrown around a bit.

I'll state up front: GWT has obviously been used to create some compelling applications. They aren't especially pretty, but they are effective. But I have a big problem with this belief that if you just ignore JavaScript and let your server code handle it, all will be well in the world.

First of all, JavaScript can not and should not ever be thought of as the output of a compiler. When Java is compiled to bytecode, the results are merely a different representation of the same functionality. There is no difference between the capabilities of Java and of bytecode. JavaScript, however, is an entirely different language, with a different syntax, and a variety of dissimilar runtimes. It is not possible to "compile" from Java to JavaScript with anything like the validity of an actual compiler.

And, once so "compiled", the debugging story is a nightmare. You have written Java, but run JavaScript. Errors in your Java code appear as JavaScript errors in a browser. JavaScript errors in the browser must be traced back to Java code on the server. The abstractions here are not just leaky; they are we've-hit-an-iceberg perforated.

Glenn Vanderburg said it best at one of the panels: we, as an industry, don't understand the interplay here enough yet to hide it away behind abstractions like this. Perhaps that day is coming, but for now, the JavaScript in an Ajax application should be treated as a codebase in its own right; written, maintained and tested as JavaScript.

To be clear, I have no problem with the JSF/Tapestry approach. Even though these frameworks tend to control the JavaScript that ends up in your pages, that JavaScript is treated as JavaScript by the component authors and can be viewed, and debugged, in its native form. To borrow Neal Ford's formulation: some frameworks emit JavaScript and others excrete it. As much as possible, try to stick to emissions – (insert your own joke about excretions here).