Skip to content

Thank God – Java EE Is Not Like Ajax

2006 September 27
tags: , ,
by Coach Wei

It is shocking that some people would actually recommend “Java EE to be more Ajax-like”. Java Developer’s Journal reports in story “Why Can’t Java EE Be More Ajax-like“?) that Cincinnati-based Brandon Werner’s blogged:

“AJAX is not a set of any one company’s technologies, and there is not even a ‘reference implementation’ of it. You are free to use any backend you want, use any persistence you want, and even implement your own call-backs and improvements. The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can’t JEE be more AJAX like? Why do we have to politically migrate towards these reference JCP technologies when the actual, real JEE patterns don’t give a damn what you use?”

What? I couldn’t believe my eyes when I read the news story. I followed the link to read the original post, and I still could not believe my eyes.

“The only thing Ajax is are a set of extremely important best practices and patterns”? Ajax best practices and patterns may exist in some elite developers’ heads today. Majority of the developers are still yet to understand what Ajax is. There is a huge need for guys like Dion Almaer at Ajaxian.com because Ajax best practices and patterns do not exist yet. Ask Scott Dietzen at Zimbra – he will tell you the pain and the challenges in writing Ajax -based applications. I have been writing Ajax applications since 1997. I was and am still hoping for the day that Ajax best practices and patterns would materialize.

To make Java EE more like Ajax? Which aspect of Ajax that 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? Even the same browser does not necessarily offer the same support between different versions. I have to spent two weeks to make AjaxWord to work on Internet Explorer 6, though it was fairly tested on IE 4 and IE 5 a few years ago.
  • The immaturity of Ajax technology (and hence the extremely slow rate of reaching maturity given that the technology was developed almost ten years ago)?

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.

Let’s do not lose sight of where we are despite our excitement about Ajax. The Ajax wildfire does not mean Ajax is the best model to emulate. Ajax as a technology is still fairly immature, incompatible, hard to develop and hard to maintain. Look at what Yokav Fain says about Ajax:

“I was always skeptical about AJAX. This technology can be useful for Google , Yahoo, or Amazon, and the like . Because regular businesses can not afford it. They can not hire a team of experts to find workaround for dozens of serious problems browsers/JavaScript introduce. Browsers/JavaScript is not an application development environment.”

Further, talking about Ajax faculties,Yokav says “Fair enough. I had an impression that all of them enjoyed the technology, understood the issues, and were willing to try to solve them… somehow. I wonder if there are people who are developing Web application in the Assembly language? Just s thought“.

I respect Ajax and enjoy Ajax. I have been working hard and will continue to work hard in making it possible for ordinary developers to build, deploy and maintain Ajax applications. For example, Apache XAP (Update on 9/30/2006: I made a mistake for XAP url before. The correct URL is http://incubator.apache.org/xap) is one of the projects that I am involved for this cause. But…

Thank God Java EE is not like Ajax…and…

Though this may not be the popular thing to say, I thank Sun Microsystem for its leadership in bringing Java and Java EE to where it is today. Java EE is here, stable, robust, has been powering thousands of mission critical business applications and has enabled an entire generation of software companies, products, developers and an entire eco-system that is based on open standards and open architecture. – All these are because Java EE is not like Ajax.

I hope OpenAjax Alliance will play a similar role in brining Ajax to a level of maturity, interoperability and openness, and I hope people recognize the problems facing Ajax and let’s all work together to fix them, instead of being blinded by the Ajax Wildfire.

from → WebDev

  • jb

    Amen, brother. I can't even count anymore the number of times I've seen government agencies trying to force AJAX onto projects with completely unqualified developers. Its been very frustrating. But what are you going to do? It is the latest buzzword. I just try to minimize the impact of the attempts and make as painless as possible.

  • Anonymous

    I agree 100%.
    Fundamentally the problem with Ajax is JavaScript. It's just too lame a language (weakly typed/dynamically typed) to be used for enterprise level applications. There is no such thing as a JavaScript framework because any function can take any numbers of parameters of any type. And there's no name spaces and no encapsulation.
    Unless a widely adopted type safe script language happens Ajax will always be difficult.

  • Anonymous

    I worked for a startup that used AJAX-like client technologies as early as 1998. Then at my current employer I helped develop a rich web client in 2002 and 2003.
    After deciding we were unlikely to meet our goals for usability, performance and richness of data presentation in the browser environment, we put the web client into maintenance mode and developed a Windows Forms “Smart Client” starting in Q3 2003.
    For me there is no going back. In some imaginary world where our user base was as large as Google or Yahoo, the pain (to both users and developers) of a web-based client might be justifiable. But in the real world of our limited budget and much smaller customer base, the functional advantages of a web service-connected desktop application far outweigh the hassle of requiring traditional installation and upgrade.
    If your customers aren't even willing to do an installation, how much is your software really worth to them anyway?

  • <a href="http://www.newio.org/">Chris Nystrom </a>

    I think they are both the wrong path. The web was designed as a hypertext document system, not an application system. Instead of kludging the web to try to run apps, we should create a new system. I have started a system called NewIO (http://www.newio.org).

  • Anonymous

    link to
    http://incubator.apache.org/xap/
    is broken in post.

  • Anonymous

    AJAX is Google's shadow and the entire developer community is mistaking it for reality.

  • <a href="http://ali.as/"> Adam Kennedy </a>

    You don't need to hire a ton of people to find workaround.
    You just use single JSAN modules ( http://openjsan.org/ ) modules that solve that one problem, where the authors of any particular module have already done the platform abstraction work.
    Just take a look at the JSAN implementation of HTTP.Request. It's got all sorts of crazy stuff in it, from selecting the backend at compile time to a safari special case to IE leak avoidance and some thing I don't quite understand that somehow stops pre-2006 Mozilla browsers crashing.
    They've already done the work, so you don't have to.
    It's the same way CPAN works, and PEAR and any other package repository that has to deal with differing platforms.

  • <a href="http://www.jackslocum.com/"> Jack Slocum </a>

    I disagree 100% with this article. Obviously the author has not spent enough time working in JavaScript to develop their knowledge to a similar level as in Java. The list of “The difficulty in developing Ajax code, The difficulty in maintaining Ajax code” etc is so far from the truth and blatantly shows a lack of expertise in JavaScript development.
    I work in a JavaEE + JavaScript/Ajax environment and as someone equally confortable in both, I would say that not only are JavaEE apps SIGNIFICANTLY less responsive, but they take about 3 times as long to develop.
    Take the time to learn JavaScript – I mean really learn it – and I promise, you will come to hate the time you have to do server-side Java development. The speed of development and flexibility of JavaScript is refreshing after working in JavaEE.

  • Anonymous

    You should read what Doug Crockford has to say about this. Ajax may be immature, and browser implementations of javascript may vary in quality, but the language itself is really not bad.

  • Anonymous

    Hmmm I just don't think the comparison makes any sense. Ajax is a technology, J2EE is a platform. The statement “Why can't J2EE be more 'AJAX'?” doesn't make sense on a number of levels.
    Also, Coach Wei, you prove your lack of understanding of both AJAX and J2EE. There's nothing preventing anyone from writing solid applications that are delivered using mechanism that involve AJAX, and there are a number of solid frameworks around that don't require anyone to write Javascript

  • Anonymous

    I agree with this posting except that it goes further.
    An AJAX approach allows for:
    1. Highly interactive
    2. The user can be guided through an application just by disabling/enabling what he/she may do. Thus, the workflow of an application is guided much much easier than with a server side / J2EE / “paint the screen each time” solution.
    3. Since the rendering is done in the client there is no need to save client state in the backend. Thus:
    4. Calls to the back end can be more transactional in nature.
    5. Developers can work their own portion of an application and develop their own “groove” without having to necessarily impact other developers' work.
    6. This allows more developers to take ownership of their portion of a project with less fear that some other developer's work will cause their work to break.
    7. The directness of the approach, coding in a more explicit manner, allows for easier maintenance since relying on implicit rules is minimized.
    8. A non-interactive non-AJAX approach that most web pages use, especially when using various filters, forwards, and implicit rules is roughly equivalent to the “old days” where programmers used the GoTo. AJAX is more of a “go-sub” or “function or method calling” style of programming as was taught in the latter-procedural days of programming. It's simply more easier to debug.
    Thank Heaven I'm not tied down to use any J2EE solution for controlling applications. My boss, who just got burned on an XML/Struts framework by somebody else, is extremely happy with the solid performance of an AJAX approach using a straightforward transactional style Java servlet/jsp back end to get the work accomplished. No chanting of OO mantras, facist “best practice” goosestepping marches, pretty but useless pictures and diagrams to show the progress we should be making. Nothing but true results! Applications that work. When something replaces Javascript on the client side there will be little change on the back end. Just substitute the whatever-it-is-when-it-happens on the client side and it will be better than the current AJAX.

  • Anonymous

    It would not be better to use the browser to show only HTML, extend HTML document oriented tags with application oriented tags, SVG and use a protocol designed for applications not one for download documents like HTTP? A protocol like X11 but with HTML, DOM nodes and DOM modifications. A stateful protocol without cookies, binary, designed for minimizing the amount of data traffic needed between server and client. An asynchronous protocol with witch server can send HTML pages and DOM modifications to the client/browser at any moment and the cliente/browser shows the HTML, make the DOM modifications and sends function execution request to the server with user input. Just some ideas

  • David Tinker

    AJAX development is a whole lot easier, quicker and less fragile with the Google Web Toolkit. Write all your client side code in strongly typed Java and let the GWT Java->JavaScript compiler work around most of the browser specific issues. GWT also integrates very nicely with Java servlets and so on so fits in well with J2EE.

  • Anonymous

    AJAX more difficult than J2EE?
    Is this a joke?
    There was, is and will probably be no development framework more complicated and outright infuckingredibly more difficult to apply that J2EE.
    As for reliability, performance or maintainability, that huge pile of jspelled bloatware is the worst sucker ever produced by the software industry. The “synchronous share-everything” model itself is an oxymoron to start with. Adding a ton of layers (like JBoss) or an MVC framework that need 26 steps to get an “Hello World” (namely Spring) can't help.
    Wake up, Y2K is over, the bubble bursted and Java is cold now.
    The metric is “less code”, the purpose is “more applications”.
    And J2EE can't deliver none of the above.

  • Anonymous

    With regard to the “difficulty in developing Ajax”, isn't that alleviated by the numerous toolkits that are out today (i.e. Dojo, General Interface, Bindows, etc.)?
    I would agree with your comments if you are *not* using a toolkit, but the general consensus is to use a toolkit.
    With regard to “best practices and patterns”, Bill Scott and his team at Yahoo! have a terrific UI patterns library which focus around Ajax. It is also supplemented by their UI Library. Note also Mike Mahemoff's site on Ajax design patterns.
    I *think* Ajax is getting there!

  • Anonymous

    Interesting then why would you promise a ajax product called arex to your customers? Are things not going well on the way of developing it? On the other hand, what Ajax (Asynchronous Javascript and XML; whatever it would make sense against) gotto do
    with J2EE web application development platform? As far as I know, Ajax(!) based interfaces would be complimentary front end to a J2EE based web tier. What is wrong here?

  • Anonymous

    can scripting languages ever be as safe as a compiler checked language?

  • Coach Wei

    aRex is designed to solve some of the Ajax challenges.
    There are two primary usage scenarios of Ajax:
    1. HTML enhancement – Adding rich UI widgets to an HTML page. For the overall application, the UI is still mostly driven by HTML and Ajax accounts for only a small portion of the application UI.
    2. Desktop-quality web application: creating a primarily Ajax driven application (most of the client side is Ajax), such as duplicating a desktop app in a browser using Ajax.
    I personally think:
    1. Writing Ajax code from scratch without any toolkits or framework is hard in any use scenario;
    2. Ajax toolkits are good for use scenario 1 (HTML enhancement), but may not be sufficient for use scenario 2, which is much more demanding and requires a lot more work;
    2. Ajax frameworks are probably good for use scenario 3 (depending on the framework).
    aRex is a framework (built on top of Ajax toolkits, for example, Dojo by default), targeted at use scenario 3.
    Ajax is hard and difficult -which is why you see so many toolkits and lots of frameworks. They are all trying to solve some of the Ajax pains. How successful they can solve the Ajax pains? The short answer is that we don't know. We have yet to wait and see how much these toolkits and frameworks can help.
    I personally think aRex (and Apache XAP) can be of great help here – but of course, if you try them after they reach production quality, it is up to you to tell me whether they are helpful or not.

  • Will

    We're scrambling out a prototype in EJB3 right now.
    It's pretty simple but functional.
    But, because of EJB3 and its simplicity, I'm able to take the compiled EAR generated for Glassfish on my PC , and plop it in to JBoss on Linux. And it works. It just works. I am amazed.
    That's a testament to Java, the JCP, and the entire development community.

  • Anonymous

    You may consider Ajax(!) as a platform, but a client platform; on the other hand, J2EE is a server side platform. Why do you think they are in the same domain? What is my X Window System application communicating with J2EE server to get data then? Can I also say “Thank God, J2EE is not X Window System”?
    I personally think there is a great confusion in your blog entry.

  • Anonymous

    I read both articles yours and that of Brandon Werner, and all of the comments, either im a complete idiot and the way down for the article to the comments i forgott the content of the article or many commenters missed they point.
    You are both right!
    JEE needs the diversity because its grown out of different technologys.
    AJAX is in that way immature that the browsers each supports its own javascript.
    Sure Ajax Best practice and Patterns would ease the developement process but how many java developers never used or even looked at patterns and don't let them be influenced by best practices.
    Calm down, think again, and don't burn the ropes to the opposite.

  • Vivek

    Agreed, AJAX isn't the best technology to compare against JEE (.Net would've been a better choice!). But Werner does have a point.
    Sun has a long history of pushing Built-Here technologies as replacement to already well-established third party technologies, sometimes even re-inventing the wheel – as in the case of JDK logging vs. Log4J, JSF vs. well-established Tapestry.
    I 100% agree with your assertion, that 'Standards' are a must to have compatibility, and succeed without the need to re-invent the wheel, be it a widely accepted one like HTML, Javascript or even limited-to-project Coding standards.
    Issue isn't with the 'Standards', but in Sun pushing it's own instead of just blessing other proven third-party technologies and moving on. Think of the effort that got wasted in implementing JDK Logging, when Log4J was already well-established and stable. A lot of man power is still being wasted in developing a component framework JSF, while Tapestry has been around like 10 years.
    Those Person-Months wasted elsewhere, could've been better spent at developing newer and better technologies. For e.g. in providing a JEE/J2SE caching framework, unified Security model, and other meat needed to beat the competition. DRY must have been the Java mantra, when a standard technology demonstration implementation like PetClinic has been turned a laughing-stock by the competition ( benchmarking with the .Net Pet Clinic )
    To be realistic, JEE is as fragmented as AJAX and here's why -
    1) JEE security doesn't work with JAAS (per recent java.net article by BEA security architect). JEE security implementations by various vendors are are also incompatible. It comes as a surprise that there is no one single security standard in Java ENTERPRISE Edition, when security should be the No.1 Enterprise concern. Also there's no JEE standard for implementing 'Single-Sign On' across domains (correct me if I am wrong)
    2) The so-called standard EAR files need vendor-specific XML files in them to be deployed to JEE servers. Weblogic.xml for BEA, and ibm-*.xml for WebSphere. I understand the vendor-value addition concept. But even simple configurations like configuring 'DataSources', JMS Topics/Queues etc. remain totally vendor specific. No standards apply here.
    3) Further, the stubs and proxies created are vendor-specific. There is no binary compatibility. You cannot deploy a EAR developed for Websphere in Weblogic. It won't work. JEE provides source-level compatibility (like C++) and not Java-like compatibility (same .CLASS will run in Windows and in Unix). There's significant work involved in supporting a new JEE vendor.
    On the one hand JEE appears half-baked (no unified Security standard), on the other too heavy-weight implementation/runtimewise. JEE stakeholders need to fix these anamolies, instead of wasting time in re-inventing more wheels.

  • matt

    Type safety has nothing to do with it. The ability to have dynamic typing and parameter lists provides additional power to the language. The only sense in which that would make a language not “enterprise class” is in the sense that the quality of enterprise developers is not sufficient to use that power. The reason Javascript has gotten much easier in the past two years is the preponderance of libraries that abstract the differences in browser implementations.
    The true issue here is that Microsoft continually deviates from web standards in Internet Explorer and attempts to delay and damage the standards efforts for their own benefit. I think Sun would have seen similar results had they allowed Microsoft to vote on the Java specs.

  • vatel

    Some clarifications:
    (2) In Java EE 5.0, in most cases you do not need deployment descriptors at all, so your EAR will work on any server. Sometimes you need some small changes between servers (but it is not so frequent; and it is not difficult to tune deployment descriptors). If you write your apps according to the specification (standard), such changes are minimized (or eliminated at all).
    As for configuring resources (DataSources, Queues, etc.), I think, this approach (platform-specific tools, GUIs, etc.) is by design – I do not see any reason why these admin/environment tools should be standard…
    (3) In Java EE 5.0 EAR is *binary* compatible. When you make EAR, you do not generate any specific stubs/proxies. This artifacts are generated at deployment time.

  • vatel

    My opinion about AJAX: I don't know where to start learning AJAX, I'm not sure where AJAX tools (IDEs) will still exist tomorrow. Even more – I don't know what (which, whose?) AJAX should I learn – by Google, by VendorA, VendorB,… ?
    Also, I don't know how to tune AJAX applications: what to do when you have OutOfMemory errors (and how to make profiling?), how to optimize performance?
    I am not sure whether my knowledge of “AJAX by VendorA” will be useful tomorrow…
    Thank God – Java EE Is Not Like Ajax…

  • Anonymous

    You cannot compare the two of them, Ajax is a technology and J2EE is a platform.
    —-
    Cartier replica watches and Panerai replica watches