Thank God Java EE Is Not Like Ajax

Slightlyright writes, "Java Developer's Journal reports that some people in the community are wishing that "Java EE would be more Ajax-like because 'EJB 3.0 can not save Java EE.' This has caused strong reactions from bloggers such as Rich Internet Application pioneer Coach Wei, who wrote: 'Which aspect of Ajax [do] we really want Java EE to be like? The difficulty in developing Ajax code? The difficulty in maintaining Ajax code? The extreme fragile nature of Ajax code? The extremely fragmented nature of Ajax support from different browsers?'"

Re:Which aspect of Ajax?

[TubeSteak]

And I found this part of TFA interesting:

"What else? The difficulty of finding and hiring Ajax developers? According to Rod Smith (IBM) and Scott Dietzen (Zimbra), both independently mentioned that one out of 40 engineers interviewed would be qualified to learn Ajax."

Not qualified to code,
qualified to learn

AJAX between JS and Java servlets

[tepples]

What does Javascript have to do with Java?

ECMAScript code on the client manipulates the HTML DOM and requests data in XML or JSON format from a server through XMLHttpRequest. A servlet [wikipedia.org] produces such data.

GWT

[HappyEngineer]

I just searched through these comments and didn't see any mention of GWT.

GWT is wonderful. I've programmed ajax stuff (check out my chess and checkers games [tryit4fun.com]. It's definitely brittle if you actually have to write the javascript and parse the xml and convert the xml to java objects manually.

But, using GWT has been a big eye opener for me. You write java code and it's compiled into javascript. It completely turns everything on its head. If you want to communicate some more information to the server from the client, all you need to do is add another method to the remote object (and its interfaces) and you suddenly have another statically type checked rpc call between client and server.

I'll probably still do simple form apps in struts, but I don't intend to ever write another line of javascript that's of any significant complexity. It's no longer necessary. No longer do I need to figure out incompatibilities between browsers. GWT just figures it out.

All these years people have been trying to make a good java webapp framework and GWT comes along and does things in a way that just turns everything on its head. Struts and Tapestry and JSF are all solving the wrong problems. They all try to make it easy to take html forms and retrieve and validate that information.

GWT turns it around and just lets you communicate java objects. I used to be unhappy that I needed to settle for choosing which framework was the least bad. Now I just say to hell with the lot of them except in situations where javascript isn't allowed.

Re:Which aspect of Ajax?

[julesh]

There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.

Re:What does AJAX have to do with Java?

[Dan Farina]

Reflection.

The Java runtime can handle dynamic discovery and execution of procedures in any old Java class file, passing around Method objects and such. This falls short of first class functions and very short of closures, but that's how it's done.

Re:Which aspect of Ajax?

[Osty]

There's somewhat more to writing a large-scale AJAX application than "understanding a javascript function call". You have to contend with multiple implementations that work different ways. You have to work around the fact that javascript has little or no support for techniques that are typically used in writing large applications. Modularising a javascript application is hell. The method of defining a class is bizarre. Inheritance is horrible, particularly if the class you're inheriting from is in a different file, because there are no guarantees about the order in which they will be loaded. Multiple inheritance...? The language can do it, sure, but it isn't trivial.

And you've just proven that you don't understand JavaScript. JavaScript != Java (or C++, or C#). It's not designed around functions and classes. Javascript is a functional language [msdn.com], and as such is designed around closures. Closures allow you to define classes and functions, but they also allow you to do quite a bit more (and also let you shoot yourself in the foot if you like).

You're correct in saying that there's more to writing a large-scale AJAX application than just understanding a JavaScript function, but most of the things you mention are irrelevant (well, they're important to understanding JavaScript, but that's a core competency for any type of web design, not just AJAX). Using AJAX is easy, especially with all of the frameworks available that abstract browser compatibility issues for you. Using AJAX well is difficult (dealing with accessibility, server load, concurrency, etc).

s/Ajax/Java 1.5 + applets (or WebStart) ?

[drgonzo59]

Interesting that you mentioned that. The other day I was in a bookstore and was looking through the computer books section. There are a ton of Ajax books out there. It seems like out of nowhere we have all these Ajax experts writing books about Ajax. I picked up a couple of them and as I was reading I kept thinking that "I could do that with Java applets" or "Java + WebStart can do that".

Yes, I know Java is not cool anymore because Google uses Ajax, and I acknowledge that when Java was being hyped as the "the new cool thing" 5-10 years ago, it was not up to par: limited and ugly graphics and UI, slow initialization, etc etc.

But a lot of those things have been polished in the recent Java 1.5 and will get even better in Java 1.6. UI got speedier, many bugs have been fixed, gc has been improved and most of all the performance in general is faster. At the same time, computers were much slower back then. Now it would be safe to say that just the average raw machine performance has more than doubled, soon we will be seeing multple cores on home desktop machines. So could this be another chance for Java rich clients in form of applets or Java WebStart applications?

One of the biggest benefit of Java is that the developer can stay in the same environment, on the front end and the backend. No need to know JavaScript, HTML, DOM, XML, and whatever the backend uses. Just use one language. This, to me at least, leads to 3 other benefits:

1) More consistency: a lot of Ajax code right of the bat deals just with different browser version and JavaScript versions, that's too many "if"s and "else"s to make it fun. With Java the developer has a clean slate work with, less workarounds means cleaner, more maintainable code.

2) Can use any communication mechanism between client and server, no need to stick to XMLHttpRequest
3) Easier to find developers. On the job application just put down one requirement - "Java". Instead, Ajax means "JavaScript"+DOM+XML+backend language(SQL,C++,Java etc)....

Yes, yes, I know, I don't really see Google or Yahoo re-developing their portals as Java applets or even worse Java Web Start standalone applications. But how many large web portals are out there? On the other hand, I can see applets used more often in specialized sites, industry-specific sites.

And let's face it, most sites can just remain static. Mr. Sixpack doesn't need DOM, JavaScript and XMLHttpRequest to display his fishing trip pictures online...

Dijkstra was NOT a troll

[Kenneth Stephen]

I'm afraid you're using the wrong word. A troll is someone who doesnt even believe in the arguments that they are espousing. Their whole purpose is to dump fuel on smoldering embers. This is something that cannot be said of Dijkstra. A polemicist is a more accurate description of who Dijkstra was.

Re:Python? Who said Python?

[nuzak]

> I love Python, I wish JavaScript would be Python (i.e. a browser would come with an embedded Python interpreter and a library to communicate with the server).

Check out Mochikit. It's very close to what you're looking for, and being "pythonish" is its main goal. I find it a nice happy medium between Prototype (a thin hacky wrapper around raw ajax) and Dojo (makes you drink the koolaid with its use of custom tags).

Actually I really like Ajax4JSF, but that's a very different beast.