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?'"

Comments

You mean the buzz?

[quick2think]

I Think Java developers are more in need of the buzz java once had. A CEO looks at AJAX as better, because of it's recent exposure, and buzz word power. Java was no different in it's infancy, with it's broad promises. Java justy wants to be cool agaim ...

Re:You mean the buzz?

[bcat24]

I think you just hit the nail right on the head. CEOs and marketing types want the latest, "greatest", buzzword-compliant software. Old standbys are no longer will probably work just as well, maybe better, but they aren't cool. Actually, geeks aren't immune to this problem either. Being on the cutting edge is fun, and sometimes we forget that old, tried and proved techologies lasted so far for a reason.

wow, what an excellent point!

[Anonymous Coward]

When the guy in the first article said we must stop thinking about "faster bubble sorts"... well, that really hit home for me. Why, me and my buddies spend hours a day trying to improve bubble sorts. Sometimes I wake up in the middle of the night, thinking about bubble sorts. It's hard, man, once we came up with this recursive divide-and-conquer approach--looked not so slow, even quick, but then we realized it wasn't really a bubble sort so we couldn't use it in our programs. Back to the drawing board.

Anyway, just wanted to say that I immediately realized that SOA guy was a real engineer--skilled, one of "us", not a marketroid at all--when I read that quote.

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 produces such data.

Re:AJAX between JS and Java servlets

[Anonymous Brave Guy]

I'm not sure what's more terrifying, the number of buzzwords in the one-sentence parent post, or the fact that I understood them all.

:-p

Java EE is *different* from AJAX, and vice-versa

[mritunjai]

I am disheartened by reading the comments... people, PLEASE for once in life go and read Java EE specs and see what it is intended to do.

Java EE is a framework to write business applications, for any kind of business, from issue trackers to ERP, the "business" in it doesn't mean "$$$ business" literally.

When writing business applications, it tries to enforce you to separate your concerns, especially, the presentation layer (Servlets & JSP), the business logic (EJB) and enterprize information systems (EIS) (JDBC, EJB container managed persistence etc). Its a complete stack for developing applications.

AJAX deals with presentation layer, and more specifically, the interaction part of it. its a piece in the whole stack. The Java EE presentation layer does NOT depend on even having an HTML frontend even! (no sane framework does!).

So now, if you have an HTML/XML browser frontend and a human user using it, you may use AJAX for enhanced user experiece. There is nothing in Java EE that says you cannot take your favorite AJAX toolkit and use that to build your frontend.

So both technologies are not even competing on even a single issue. Both are complementary. You can use Java EE stack to develop your application, and when time comes to develop the frontend, you choose from plain old HTML, XHTML, XML, AJAX etc (or a combination thereof), to develop your application's "frontend".

Please stop this ignorant war. To make another bad /. analogy, its like car lovers and music system fans fighting with each other that the other is not like their's!

RTFA!!!

[SanityInAnarchy]

For the love of all that is holy, RTFA! The claim was not that Java EE should use Ajax, or that Java developers should use Ajax at all. Google Web Toolkit is completely irrelevant!

What was meant by this is that Ajax is a loose collection of cooperating technologies, without a standard, that develops very rapidly, and allows a lot of choices to the developer -- as opposed to Java EE as a rigid platform. Kind of like Linux vs BSD.

Even TFA understood this in the response.

The Slashdot response, so far, is roughly equivalent to if I said I wish Java had something like CPAN, and people jumped all over me with comments like "You want Java to use :: as the class separator? You want all variables to have dollar signs on them? You want no type checking, and all kinds of random C code?" Completely missing the point, of course. CPAN is a centralized collection of community modules, most of which play nice with each other, which make it possible to develop most Perl programs by splicing together 4-5 modules with <100 lines of glue code containing your actual program logic.

It's like a Wikipedia of code -- NO! Not in that anyone can edit any module. It's like Wikipedia in that it's a central repository of the collective programming skill of mankind. It's sort of the library to end all libraries.

Anyway. -1 Offtopic to the entire comment section this time. RTFA!

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, 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).