XUL Based Web Applications. Why Not?
XUL Based Web Applications. Why Not?
Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
XUL support in ItsNat is easy because the approach “The Browser Is The Server” fits very well with management in server of any namespace natively supported by the browser, in fact, ItsNat already supports pure SVG pages.
XUL would allow development of remote (client/server) web applications that are very similar to desktop applications. Using XUL components could be added/removed/updated from server and sending client events to the server using AJAX (if some listener was registered) with no reload following the Single Page Interface pattern (in fact XUL was not designed for page based applications).
The “free” components of ItsNat can work with no problem with XUL markup, as it does with SVG. The problem arises around interactive XUL components like checkboxes or listboxes, components similar to the HTML counterparts (input checkbox select). In these kind of elements we can use the low level event system of ItsNat to synchronize the server DOM when the control changes in client. Nevertheless, custom components would be interesting providing data models, selection listeners etc, much like in HTML. The se new components are not done, this make me think is there enough demand?
As said before, XUL is not new. To add some example to the manual I have been searching XUL code and applications based on XUL, and the findings have been very disappointing. Most of the examples, tutorials, and articles are very old. Is XUL interesting and popular enough to spend any resources on it? Will be someday? Are there XUL applications beyond the FireFox chrome and fancy add-ons?
Why is not XUL popular? I have found some answers:
1) It is a technology only working in a single family of browsers (Gecko).
2) In spite of the fact that it can work remotely (XUL code served by web servers), the main purpose is to provide the desktop experience to the user. The focus is not page navigation, in fact XUL does not have a form tag (the HTML form can be used).
3) Web frameworks have largely ignored XUL. You can find some basic support in action frameworks and template technology allowing free design. I can't find (I haven’t) a server centric framework with support of XUL and AJAX.
Item 2 is not longer a problem because current trend is to avoid so much as possible the ugly page reload per request, XUL focus for desktop is currently an advantage for web applications, page reload can be fully avoided using AJAX.
Item 3 can change, may be ItsNat is the first framework server centric with XUL and AJAX support.
In summary, the first paragraph is the main unsolved problem, true XUL applications only work in Gecko browsers. Fex and AIR are proprietary solutions trying to conquer the world of application development outside the web (Flex runs on top of the web), why can not XUL, a really web based technology, be a first class technology?
Flex is executed on top of Flash plug-in, what about an Active X embedding FireFox in Internet Explorer? Why is this Active X abandonware?
In desktop Prism is trying to push FireFox as a platform for desktop applications much like AIR is doing, why not these applications in XUL?
Can XUL have a rebirth as a web application platform? Can the XUL component system be a future standard for web development adopted by other browsers? Or is it too late?
Opinions expressed by DZone contributors are their own.