Linux Today Article Recommends Sun Adopt XUL for Java

Friday February 27th, 2004

Tomas Marek (marek<AT>tipsport<DOT>cz) and guzzi333 pointed us towards a Linux Today article in which Ganesh Prasad argues that Sun should levarage the work of the open-source community to improve enterprise Java and fight back against Microsoft's .NET. The author singles out client-side rich user interfaces as an area in which Java is weak, and recommends that Sun adopt XUL to fill the gap. This would help to combat Microsoft's XAML technology, which is similar to XUL and designed to work well with .NET applications. Prasad also claims that Sun could give credibility to XUL and encourages the company to work with the Mozilla Foundation to get the language endorsed as a W3C standard.

#27 Simple things first

by gfisher365 <>

Thursday March 4th, 2004 3:55 AM

You are replying to this message

Some contributors to this subject are running too far ahead.

The Mozilla render engine Gecko contains the kind of widgets that XHTML renderers do not possess. For now, all I wish to do is substitute XHTML by XUL when delivering content to my browser clients so that I can tap into those rich widgets. I'm already using Javascript and CSS. In a nutshell, I replace one XML vocabulary by a more advanced one. That way I can migrate my IT application UIs on to a web browser and give my users more flexibility.

All this talk about what you might or might not do with Swing/SWT is getting far ahead of the story. Let's deal with what is required now - web-based rich clients that are very messy and difficult to produce with XHTML. Yes, I know XPFE is capable of more but for now let's address an immediate doing the simple stuff first and see where that gets us.

If Sun/Swing/NetBeans or IBM/SWT/Eclipse choose to use XPFE to unify the thin and thick clients then all the better as far as I am concerned. And if they choose to use XUL only for describing content to be rendered by some component of the JRE then that's fine with me too. I'd like to be able to create just one content that is capable of being rendered as either desktop-based or browser-based application.

Let's see what is produced before judging the merits of each offering.