Desiderata Releases Jaxcent (Java AJAX) for the Internet

Discussions

News: Desiderata Releases Jaxcent (Java AJAX) for the Internet

  1. Jaxcent from Desiderata Software is a Java API for accessing and modifying the Document Object Model (DOM) of the browser. Version 1 of Jaxcent worked entirely on the client side. While it explored some possibilities of doing AJAX-style operations in Java, it was best suited for intranets and special scenarios such as automated testing and automated browsing. Version 2 of Jaxcent is an unrestricted Java API for doing full-fledged AJAX operations. It can be run on the open Internet instead of being restricted to intranets. The Java of Jaxcent now runs on the server side, and still gives the Java programmer full control over the client's DOM hierarchy. On the client side, all that is required is to add a single JavaScript include statement to existing HTML content and then the resulting page can communicate with Jaxcent on the server. On the server side, Jaxcent works with standard Java servlet containers and provides classes that correspond to elements of the Document Object Model (DOM), and that can be instantiated to match HTML elements existing (or dynamically created) on the page. These classes provide methods for interacting with the HTML elements, and for receiving events originating from the HTML elements, all in Java. In addition to dynamic interactions with the HTML elements, Jaxcent also provides access to the session and application context, as well as entirely automatic session data management. It is not necessary to rewrite existing applications to take advantage of Jaxcent. Using Jaxcent, as needed, one or more AJAX features can be added piecemeal to one or more pages without any need to modify the structure or specifics of the overall application. For new web applications the entire framework can be built using Jaxcent, taking full advantage of its dynamic capabilities. Jaxcent works with AJAX capable browsers, such as Internet Explorer 6, Internet Explorer 7 and Firefox. Jaxcent is written entirely in Java and JavaScript, and therefore is OS independent. Jaxcent programmers do not need to work in JavaScript. Jaxcent will work with any existing JavaScript code, and it provides features to take advantage of JavaScript if desired, but primarily Jaxcent programming is all-Java and no-JavaScript programming. Jaxcent Version 2 is available free from Desiderata Software, at http://www.jaxcent.com/ Version 1 of Jaxcent will no longer be available. For those who need it for its non-AJAX features such as automated testing or automated browsing, Desiderata's EZ JCom product (http://www.ezjcom.com) can be used. EZ Jcom builds bridges between Java and COM, or Java and .NET. It can be used to automate - among other things - Internet Explorer from Java.
  2. A bit too thin framework[ Go to top ]

    Server-side Ajax frameworks are, in my (possibly biased) opinion, a very important development. Having taken a peek at Jaxcent, it seems to have the client-side rather thin. DOM and HTML generally are really low-level client-side stuff and should, in my opinion, be abstracted away from the server-side API. You really shouldn't have to program HTML/DOM in the server-side. Besides, HTML and DOM are somewhat browser-dependent. My (possibly biased) preference is on server-side frameworks, such as our IT Mill Toolkit, that use higher-level components for defining the UI and handling user actions much you would do in SWT or Swing or other desktop UI frameworks. Looking on the positive sides, I think the client-side JS engine could be really tiny in such a solution. Looking at Jaxcent, however, it's js engine seems to be about 66kB, which is bigger than I would expect. In IT Mill Toolkit, the client-side JS (compiled with GWT from Java) is around 80 kB, but it has huge amount of client-side functionality. Much of the browser compatibility issues are taken care of by GWT compiler and the client-side engine of the framework. While I'm myself working on another Ajax framework, I'm always interested to see new solutions. So, I would like to hear some arguments for the purpose of Jaxcent. In what sort of applications is it expected to be better than existing frameworks?
  3. IT Mill seems not very mature (I didn't try Jaxcent yet). If you prefer the server-centric Ajax solution, I'd suggest ZK. Complete and powerful yet intuitive and simple. Of course, I might be a bit bias after using it for almost one year.
  4. IT Mill Toolkit itself is very mature and has been used extensively in many client projects for years. The new generation, Release 5, which has a new GWT-based client-side engine, is still in beta phase. If maturity is your primary concern, you could use the previous Release 4. We still support it fully and the next release (4.1.0) should come out in February. I don't really like comparing "mine is better than yours", but while ZK seems to have a good amount of ready components and demos, the programming model seems problematic. You have to define the UI with an exotic UI language (XUL is exotic and ZUML even more so). With IT Mill Toolkit (and some other server-side Ajax frameworks), you just create the UI components as normal Java objects and can handle them very dynamically compared to a declarative approach. I understood that ZK has such a way of programming also, but why have a mixed model? Just learning a Java API that is very similar to SWT or Swing should be enough. Actually, ZK has a third language, JavaScript, for its client-side engine. IT Mill Toolkit has GWT-based client-side engine, which makes it possible to program it entirely with just Java, if you ever need to make new widgets on the client-side. That said, I haven't actually used ZK, as you probably haven't used IT Mill Toolkit. They seem to have many similarities, but I find it hard to accept that using XUL in addition to Java would make GUI development any easier.
  5. Use before judge[ Go to top ]

    ZUML is an option. With ZK, you can choice whatever you want: by a markup language, by program, by JSF components, by JSP tags... I don't like to jump to the fight. After all, the more competition the better for developers.
  6. Ease of use?[ Go to top ]

    So, I would like to hear some arguments for the purpose of Jaxcent. In what sort of applications is it expected to be better than existing frameworks?
    Java developers usually know HTML (which is highly standardized across browsers these days.) Learning one of the many specialized toolkits has the possibility of learning something that will go away -- whereas working with the Jaxcent API does not require much new learning, as it pretty much wraps HTML tags and their behavior into Java. Also, the intent with Jaxcent is that developers don't have to mess around with any JavaScript, which may be preferable to many Java developers. But I am possibly biased too, like the original author! It would be good to see something from other people who have evaluated different toolkits!
  7. JavaScript size[ Go to top ]

    Looking at Jaxcent, however, it's js engine seems to be about 66kB, which is bigger than I would expect.
    The JavaScript compressors can bring it down to about 19KB, even just removing whitespace would probably compress it significantly. The Jaxcent release uses fully uncompressed JavaScript. There doesn't appear to be any actual performance impact! Probably because there is a single JS file and the browsers just cache it. But if comparing against other frameworks, the level of compression should also be considered. In particular, GWT is supposed to generate very compact JavaScript!
  8. Jaxcent seems a minimalist version of ItsNat :) Marko Grönroos: "DOM and HTML generally are really low-level client-side stuff and should, in my opinion, be abstracted away from the server-side API. You really shouldn't have to program HTML/DOM in the server-side" OK, but in the real world many people *want* to *keep control* of the HTML layout and doesn't like very much frameworks saying: "hey your HTML is wrong, see my amazing HTML layout and cool effects, they are the appearance and functionality YOU MUST WANT".
  9. Jaxcent seems a minimalist version of ItsNat :)

    Marko Grönroos: "DOM and HTML generally are really low-level client-side stuff and should, in my opinion, be abstracted away from the server-side API. You really shouldn't have to program HTML/DOM in the server-side"

    OK, but in the real world many people *want* to *keep control* of the HTML layout and doesn't like very much frameworks saying: "hey your HTML is wrong, see my amazing HTML layout and cool effects, they are the appearance and functionality YOU MUST WANT".
    Also, possibly people missed this advantage of working directly with HTML tags: the Jaxcent "thin" serverside approach even lets you add "a little bit" of AJAX to any of your existing pages, without affecting the rest of the page or application behavior.
  10. So I'm wondering how about Echo2 in your opinion. I've worked on Echo2 for one year but there're always the performance problem even after I refactored my code again and again. Is it worthy to refactor it again or just change to GWT? TIA!
  11. So I'm wondering how about Echo2 in your opinion. I've worked on Echo2 for one year but there're always the performance problem even after I refactored my code again and again. Is it worthy to refactor it again or just change to GWT? TIA!
    Can't comment about GWT and Echo2 -- in Jaxcent, performance issues aren't quite gone! If you look at the samples on the website, they are reasonably responsive given the server power and load. (Well, if the client browser is in China, the chat messages will probably take a second or two while they make the round trip to the server in Dallas...) But that performance did require some thought, at least in a couple of the samples. Not so much refactoring, as reduction of round-trips. The document "Getting Started" (available at the Jaxcent web site), has a section on performance considerations. The internet has gotten pretty fast, but for general-purpose websites (where the client browser could be half way around the world) excessive roundtrips can still kill the responsiveness. That's why in Jaxcent, overloads are available to fetch all form data in a single message, and output data can be batched so it could go out in a single message. So without knowing too many details about your situation, here is the advice I can offer: Focus on reducing the roundtrips. Save the refactoring for when it's time to make the code easier to maintain!