Simon Phipps blogs about the marriage of Java applets and AJAX, suggesting that AJAX applications could benefit from having access to the rich Java APIs. But would the marriage of AJAX and Java applets turn out harmonious, or end in divorce?
In his blog, Simon Phipps comments about a demo that Francois Orsini, Sun's Java database lead, gave at ApacheCon. The demo allows JavaDB—Sun's version of the small-footprint open-source Java database also known as Apache Derby—to persist data created in an Ajax application. Francois himself described the demo as follows:
What might they do? Some obvious things, like encryption, compression, validation and so on. But also some more interesting things are possible. How about a tiny Jabber server so the applet can use the local IM client as a log or command prompt? Perform XML transforms (in conjunction perhaps with WADL) for multi-host compatibility? An embedded web server as per Mark McLaren? And of course, a local SQL database.
If invoking Java objects from an AJAX application became a real alternative, AJAX apps would suddenly have access to the entire Java API, including many third-party libraries. It has taken Java ten years and huge investments of money and labor to get to where it is, and it's hard to imagine that AJAX will provide a rich environment in the near future comparable to what Java has to offer today.
But are such background applets a real alternative? I always felt that the biggest problem with applets was their implementation—slow startup, incompatible behavior across browsers and platforms, and the need for users to potentially download a huge JRE to upgrade to the appropriate Java version.
It turns out that J2SE 5 already addressed many of these issues: Java WebStart and the Java Plugin now use a common architecture and implementation that allows seamless JRE updates and fast client-side caching of Java code. Applet startup time is still generally a problem, but some of that may be addressed in Java 6.
Simon's blog post hints at using Java applets in conjunction with AJAX—but what role would AJAX play in such a marriage? It's nice to persist HTML form data via an embedded Java database, but once we've incurred the applet startup time, why not display a Swing form that provides all the nice usability features that folks have invested time to design and implement over the past decade? Or use one of the Java look-and-feels to make the form look polished?
What role do you think a combination of AJAX and Java applets have on the client, if any? Will AJAX completely replace client-side Java? Or will AJAX and client-side Java co-exist, but in different applications, possibly even in different application domains?
Swing is fine for low-level GUI design, but I have been thinking about another idea. If Swing had a real functional XHTML component, with full support for CSS, it will form a great tool to build UI's. One can speify the UI in terms of XHTML controls, use CSS for look and feel, and scripting for event handling. Build IDE support for this model, and you have a very simple GUI platform with that can handle 80% of all app needs.
Extend this idea to the browser, and you have AJAX with Java, and a great platform for platform-agnostic rich client apps. I don't see applets reviving any time soon, if ever. Swing or AWT, or SWT) just isn't the right level of abstraction for most GUI designers.
> Swing is fine for low-level GUI design, but I have been > thinking about another idea. If Swing had a real > functional XHTML component, with full support for CSS, it > will form a great tool to build UI's. One can speify the > UI in terms of XHTML controls, use CSS for look and feel, > and scripting for event handling. I have done (almost) this at work. Instead of XHTML, you specify the UI in XUL, because XUL is a better fit for traditional GUIs. In the future, you will also be able to display the same GUI in a browser. Ultimately, you can use the same application as RCP (rich client platform) or RIA (rich internet application)
Compared to pure Swing, the XUL GUIs are much easier to maintain and change, especially due to CSS. Sadly, my work is not open source. Granted, there are other XUL interpreters, but their CSS support is much worse or non-existent (the last time I looked).
MS is working on a much better version of the RCP-RIA integration (XAML), which includes tool support.
> Compared to pure Swing, the XUL GUIs are much easier to > maintain and change, especially due to CSS.
This is an interesting statement, and I'd love to hear your reasons. My take is that that statement was true 3-4 years ago, but not today. Swing has many UI builders that can construct very professional UI layouts with a just a few lines of code. I've looked at XUL and some other UI description languages, and I found that Java (Swing) trumps all of them in terms of clarity of code and brevity, etc.
I most recently looked at NetBeans RCP, for instance, that lets you configure a desktop app via XML configuration files ("layers", etc). While this is an interesting concept, I just don't see why I wouldn't use Java code for the same thing - it would be quicker, and would produce an easier-to-understand structure.
Is there an audience out there that's comfortable with editing complex XML files, but is not comfortable editing a few lines of Java code? And UI design tools can, I suppose, interact with Java code and XML just the same.
Sadly, my work > is not open source. > Granted, there are other XUL interpreters, but their CSS > support is much worse or non-existent (the last time I > looked).
> Swing is fine for low-level GUI design, but I have been > thinking about another idea.
This may have been true of Swing a couple of years ago. But I don't think it holds any more today: There are a huge number of high-level components now that allow you to construct very sophisticated UIs quickly.
For instance, a tutorial on SwingLabs.org shows, among other things, how to add a login panel to any app with a few lines of code. And this is not just a UI panel, but it actually ties into JAAS and, in fact, authenticates the user:
the truth of the matter was that ajax got popular because it was FAST. it was a imperceptible update mechanism, it was an non-intrusive save or load operation, it was a colorful "please wait" notification while something was persisted. This added to user experience.
Just because the page doesn't refresh doesn't mean we're adding to the user experience. Ajaxs success is only marginally related to gui-ability. If it gets slow, and cumbersome, or feels bloated, people wont care what you call it, they wont use it again.
> > Compared to pure Swing, the XUL GUIs are much easier to > > maintain and change, especially due to CSS. > > This is an interesting statement, and I'd love to hear > your reasons. First of all, I should say what our typical scenario is. For every logical dialog, like selecting a discount reason, there are typically 5-10 visual representation (because every customer wants a different background color, etc.)
This means that it has to be easy to change some parts of the GUI without copying the whole logic. CSS can do that very nicely. Consider the following CSS example:
You can change the images in the style sheet and change the whole look and feel.
> My take is that that statement was true 3-4 > years ago, but not today. That is not my experience. But there are many possible reasons for that 1) different reqirements/scenarios 2) the XML I use is not as clumsy/badly designed as the one you saw 3) The GUI builders you used are much better than Swing alone.
> I just don't see why I wouldn't use Java code for > the same thing - it would be quicker, and would produce an > easier-to-understand structure. I'm not religous about using Java or XML. Java has the advantage that it's type strongly typed, while it's easy to get an XML attribute wrong. XML is more brief in my experience.
> Is there an audience out there that's comfortable with > editing complex XML files, but is not comfortable editing > a few lines of Java code? yes. Most of the developers that edit the XUL files, barely know Swing at all. Hence, they feel more comfortable with the XML. It is also much easier to learn and the GUIs can be changed without restarting the application.
> And UI design tools can, I > suppose, interact with Java code and XML just the same. That is true. All the GUI builders I have seen do not support hieracital GUI layout, however.
For example: The "discount reason selection dialog" is based on the "input dialog". The input dialog defines that there is a request message white on blue at position 100,100, which gets specified in the "discount reason selection dialog". The "input dialog" is based on the "popup dialog" template, and so on.
I share your concerns. A few years ago I started www.richclients.org to track emerging rich client technologies. I was hoping to see more SWT/Eclipse RCP and Swing out there, but all the buzz is about Ajax. Well, at least we are seeing more rich clients and that is a GOOD THING.
Take care, David
> > Compared to pure Swing, the XUL GUIs are much easier to > > maintain and change, especially due to CSS. > > This is an interesting statement, and I'd love to hear > your reasons. My take is that that statement was true 3-4 > years ago, but not today. Swing has many UI builders that > can construct very professional UI layouts with a just a > few lines of code. I've looked at XUL and some other UI > description languages, and I found that Java (Swing) > trumps all of them in terms of clarity of code and > brevity, etc. >
> I share your concerns. A few years ago I started > www.richclients.org to track emerging rich client > technologies. I was hoping to see more SWT/Eclipse RCP and > Swing out there, but all the buzz is about Ajax. Well, at > least we are seeing more rich clients and that is a GOOD > THING. > I think what happened was that at first AWT, and later Swing, were just so complex compared to HTML, and then there were those platform differences as well. In addition, rich-client Java lacked a high-level programming model, so those who never developed a rich client app before had trouble understanding how to structure an application. By contrast, the Web page-centric programming model is really is - you just process text in and text out on the server. Anyone can understand that model.
In the past five years or so, however, Swing has made huge progress, so it's quite possible that folks will realize that many of the initial problems are now solved. What would be especially helpful are examples that solve a domain-specific problem and show that using Swing vs an HTML-centric approach requires less lines of code, and that the resulting code is (possibly) cleaner and easier to test and maintain. However, now even HTML-centric code relies to a great extent on components (e.g., JSF), and so such a comparison really might turn out to be a comparison of component toolkits as opposed to a comparison of programming models.
I don't think the public cares or understands the difference between a an applet, AJAX, or Flash. The company that chooses a particular technology will incur a support cost in getting the right runtime on the client. For example, Yahoo messenger is a native app that people have to install, but the install is fairly simple and it self-updates. Same for Skype.
> For an in-house app this might be something to look into, > but the days of applets as an application engine for the > general public have come and gone.
> I don't think the public cares or understands the > difference between a an applet, AJAX, or Flash. The > company that chooses a particular technology will incur a > support cost in getting the right runtime on the client. > For example, Yahoo messenger is a native app that people > have to install, but the install is fairly simple and it > self-updates. Same for Skype. >
The general public doesn't need to know anything about AJAX, because AJAX is already in the browser. Flash 6 and above has a 98% browser market penetration. Java? Microsoft is ditching it and you'll see WPF/E coming out next year. Sun never learned about seamless installation from the Macromedia folks.
This whole "will there be a resurgence of applets" comes up every couple months or so. Nothing ever comes of it.
The JoyiStar AJAX WebShop development team is proud to announce the release of JoyiStar AJAX WebShop 3.0 Beta for Personal Edition. This release is a major improvement in the AJAX WebShop series, which includes a large number of new features and security enhancements. Further details and the full list of changes about this release can be found in JoyiStar AJAX WebShop 3.0 Beta for personal edition. Downloading page link is: Free Downloads Notes: Please refer to the END-USER LICENSE AGREEMENT FOR JoyiStar Corporation products when you use JoyiStar Softwares. If you have any problems or discover any bugs, please feel free to contact us, thank you!