Jono Bacon comments on how XUL could be great for providing more interactive web applications. My take on it: he’s gone off the deep end. I just don’t get what the current obsession is for having to run everything in a web browser these days.

This framework not only brings the web browser out of the dark ages in terms of the potential for interaction, but the Mozilla developers made the right choice and picked XML as the language for specifying user interfaces. See here and here for why XML not a good programming language.

This choice not only makes user interfaces extremely easy to construct (with the benefits of XML DTD validation to boot), but the fact that the interface code is in XML also opens up a whole world of potential for further processing of this interface code. There is no reason why someone could not write a thin compatibility layer to convert XUL interface code to a fake table/div/image based interface for none-XUL browsers. DTD validation == compiler validation. Now there’s a new and exciting concept. Extremely easy to construct == . As for the possibility to post process XUL, take a look at something like BCEL or most of the aspect oriented add-ons for Java that modify bytecode on the fly. I’d also question just how useful it is to be able to modify your application via XSLT anyway. The given example (converting to normal HTML for non-XUL browsers) is a throw away because if non-XUL browsers could do what you needed you wouldn’t be using XUL in the first place.

The exciting thing about XUL is not XML though. The truly inspiring aspect of XUL is the potential to standardise on Mozilla as a platform for developing complex applications. Exactly what we need. I mean all this talk about web standards and cross-browser compatibility is a total waste of time. What we really need is new ways to lock people into a particular browser by using extensions to HTML. Did I just go back in time about 5 years?

Application developers are going to need to consider how much user interface code is hooked into application logic. This is of particular importance if cross platform support is one of the goals of an application, and particularly if this cross platform support should be native and not byte-code running on a virtual machine. But XUL is effectively bytecode! Sure, it’s exceptionally verbose and slow to parse, but it is essentially a platform independent representation of computer instructions which is translated to machine code at run time – just like bytecode is. It’s probably best described as an interpreted language, but the end result is the same. Certainly there is nothing about XUL or Mozilla that is native since they made the (IMO, horribly misguided) decision to emulate widgets and use themes to make them look like the real thing.

If a developer was to write all UI elements in XUL XML instead of native code within the application logic, the XML could be converted to this native toolkit code using a compatibility layer. How is this different from writing all UI elements in Java, wxWindows or any of the other cross-platform GUI toolkits and converting them to native toolkit code using a compatibility layer? There’s no need to use XML to do this and it’s a really bad use of XML because of the inherent verbosity of XML.

This could dramatically open up the potential for a new breed of web based applications that could be cross platform and cross browser based if the W3C were to adopt XUL as an official recommendation. Yep absolutely, because CSS 1, 2, 3, XHTML, JavaScript and all those other webstandards are being so well supported by browsers now, adding thousands more functions that they need to support will solve all our problems. If one of the big complaints about HTML and JavaScript is that it’s so hard to make things work correctly on different browsers, what inherent quality does XUL have to prevent that from happening again?

The Mozilla project is proving to be capable of not only creating a strong and impressive suite of applications, but is also using the combined intellect of the development community to harness the potential for not only Mozilla based development, but development in general. I want my applications custom tailored for the task at hand and tailored to fit in well with my OS of choice. I don’t want to use my browser for everything, it’s not designed for that. I don’t want to use anything built on Mozilla because it looks so horribly out of place on OS X (which is one of my OS’s of choice). I’d also like to actually use my own processor, I paid good money to get a nice fast one, making everything a thin client makes me dependent on a) having a net connection, b) having a fast net connection and c) the server having enough horse power for all the users. If your app is going to be on my machine anyway, it may as well be standalone and leave my browser to do what it’s good at – browsing the web.