JavaScript: The World's Most Misunderstood Programming Language (AJAX vs. JavaScript Part 2)

I got an interesting comment for my yesterdays entry. Richard Rodger recommended me a site, which changed his opinion about JavaScript. In my special case, after reading this article, my personal opinion didn't changed. JavaScript is a great, object oriented, dynamic language with features like Garbage Collection. JavaScript will become very interesting for Java developers, because of Java6 integration. JavaScript can be used then as a "glue code" for integration purposes of "hard" interfaces, for implementation of flexible rules or algorithms - which is great. I like JavaScript, also because the syntax is very similar to Java. Some products already use JavaScript. You can defined e.g. in the report engine BIRT formulas and computations with JavaScript which is very powerful. In the scripting area also the languae Groovy is very interesting. Groovy can be also compiled into bytecode.
Back to AJAX: running JavaScript in browsers has the following disadvantages:

  • you have to care about incompatibilities. Frameworks like Dojo do it for you, but I compare it to the portability of Hibernate/CMP 2.0/3 code between different databases.   Such abstractions are not always totally transparent, in most cases you have still to now, which browser you are using.
  •  the idea of http and browser, was synchronous request and response at one page. Ajax and other technologies break this rule - which is an obvious hack. Nothing against hacking, but every hack needs some workaround, which are expensive to implement and even more expensive to maintain (hacks are hard to document :-))
  • the user can every time disable the JavaScript or ActiveX functionality. In this case the whole stuff will not work.
  • using JavaScript in the browser and Java on the server requires the implementation or generation of redundant (e.g validation) logic in two languages. You can of course use frameworks to generate code, but it is still not very clean approach
  • the communication between browser and server is more fine grained. It is hard to say, whether this fact will have impact to the scaleability and performance, but the developer has to consider this in the architecture and design. In slow networks, fine grained communication will hit the performance (because of latency).
  • You can build very cool webapps WITHOUT installation of additional runtime.
Using Swing (with JavaScript in Java6) you will have the same advantages, with one tradeoff: an additional runtime (JRE) has to be installed....
It depends on the project context and expecially the customer, whether an additional installation is appropriate, or not. For the most intranet applications, the installation of an additional runtime shouldn't be a big issue.


JavaScript could also be compiled into bytecode, in fact some feature of Rhino is left out in the JRE-version (see

The blog shows also a (clumpsy) work-around (

The problem with duplicated implementations for validations is a true problem, best solution I came up with is to write all common code in JavaScript and user scripting-support on the server. This is not easy to built into an existing app, of course. Also performance might become an issue.

Posted by Carsten on July 20, 2006 at 10:05 PM CEST #


All JSR-223 languages can be compiled into bytecode.
Compilation to bytecode is only possible in a JVM. In browser is this feature not so interesting :-). Redundancy is a general problem. This can be solved either with metadata (and codegeneration) or multiple deployment of the same code. Nothing else than a hack :-)

Posted by Adam Bien on July 21, 2006 at 10:47 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments