Thursday, March 31, 2005

Why XUL should stay with Mozilla

When we had to develop a client side application with a rich and dynamic (generated at runtime) GUI my first thought was that HTML was not an option. We needed a robust, operative, friendly, and well programmed GUI, in which client responsiveness was a must, and that could be somehow integrated with some additional libraries; I keep thinking my opinion was justified. However, I did like some of the benefits that HTML provided, like zero installation and updates, and specially how easy it was to generate HTML to create a dynamic GUI (in our case, a full fledged questionnaire, with all different kind of questions, validations, jumps and methodologically correct survey mumbo jumbo).

So we thought that it would be perfect if we could find an application development framework with an interpreted code and GUI language, that provided more powerful programming components and a clean interface/logic separation. In that case, we could generate the questionnaires from an internal representation easily and still have the static GUI code looking nice.

Mozilla XUL


That is how we got to Mozilla XUL. The XUL concept is an excellent one; have a very clean separation between presentation and logic, in which GUI elements are described in a quite simple XML dialect, and can be referenced and manipulated easily from a programming language. Add to that the fact that:
  • XUL widgets look as native widgets
  • almost all their attributes can be modified with CSS
  • you have a language to define new widgets based on previous ones (XBL, really cool idea) or totally modify the way an existent XUL tag is displayed
  • you can manipulate everything from an interpreted language (javascript) that has access to a seemingly impressive array of C++ components (XPCOM)
and you should be convinced that the tool must be the right one for the job. Well, don't.

In my opinion, XUL suffers from the same forced hackish style of programming that HTML GUIs impose on us. By hackish, I mean forced, unnatural and in which you end working around the platform limitation and idiosyncrasies instead of your application.

The most obvious and common problem with Mozilla XUL are the terrible security constraints. Ok, I know, they are extremely important in an open web based environment, they have to be there. But what about if I don't give a damn about security since I'm going to run in a controlled environment? You can disable the checks doing some client side configuration (or sign the application), but even so, you still need to ask for permission before doing any privileged operation. And what happens if some chrome Mozilla component (for Mozilla, if its chrome, then it was loaded from the local machine) thought that it should be running in a chrome context but it didn't? Simple, it won't work. The wizard element did exactly that.

But that is something that could be worked out (subclass the wizard, or copy/paste it in a new element), but lets take JavaScript. In my way of thinking, in an app you have an starting point, in which you may define the requirements of your program (name them imports or includes), and in where you start doing things, like creating the first window, initializing services, etc.. But hey, Mozilla is a browser, and JavaScript only gets loaded from <script> tags! So, if you want to run anything, create a window. Want to print "hello world" to the console? Create a window.

What about if a particular javascript "library" (a .js file) needed to access another .js? Well, you have to include the <script> tag in the window also. Does that means that I have to know and list all the dependencies when I want to use a particular .js? Yeap, that's it. Of course, you can write a function to import a .js file, and in fact there's jslib that already does it, and solve some of the problems. And what about namespace conflicts? Well, I'm feeling lucky, and that doesn't happen often, does it?

Now, suppose that your first window creates another window. Well, the imported javascript only exists in the context of the first window. Obvious, it's a browser! You wouldn't want one's page javavascript in another one! No problem, you can fix it. Just reference the previous window to access that code if you need it (make sure you disable the same origin security policy if you are accessing a remote page from a local one, obviously). You could even pass an object with all the needed code as a parameter to the second window. But if you do that, don't think about closing the first one, because all the rest of its code and objects will get collected, and, if later, you try to access the object you passed, it might be missing a few needed functions. You get a similar problem if a window opens a async connection (for example with a XmlHttpRequest object) and gets closed. Why, you ask me? I don't know is somewhat related to a LoadGroup of the HttpChannel object, look at the Mozilla source code and stop bugging me.

Even so, javascript is a great language. People say that you can't do object oriented programming with it just because they don't know how to do it. You can perfectly simulate OOP by using prototypes, and even define your own "uber" function to call super class methods or constructors!. And its even better, because "There's more than one way to do it". So don't look confused if you find things like:
function ConnectionListener () {...}
ConnectionListener.prototype = new Listener ();
function ConnectionListener_listen (socket) {...}
ConnectionListener.prototype.listen = ConnectionListener_listen;
or
ConnectionListener.prototype.listen = new function (socket) {...}
or
ConnectionListener.inherits (Listener);
ConnectionListener.method ('listen', new function (socket) {.....});

which shows you how writing a couple of helper functions you can transform javascript in an object oriented language! Just make sure all the team uses the same conventions or code could get a bit obfuscated.

You can even have reflection in javascript:

if (Math.round(obj)==obj) return "int";
else return "double";

this guy (which honestly deserves all my respect for just an awesome hack) even implemented attributes . Some guys also wrote (I did too, since I really missed it, and didn't like theirs :)) a framework to do some unit testing, its great but i couldn't integrate it in the build process (instead I ran it and look at the green/red bars). I suppose Mozilla developers have a way to do it anyway, but I wasn't able to find it (I didn't look at the source this time, my fault).

Enough of javascript. Its used mainly on HTML pages, an already forced abstraction, its cute to dispatch events, but (being polite) lacks of some needed constructions or standardized ways of doing things. What about Mozilla C++ components platform, XPCOM?

Well, first, I admit I wanted to avoid using XPCOM directly. When trying to be productive and coding things that I can maintain I avoid using C++ (well, I avoid it always, I hate reading it, but loathe writing it). So my experience with XPCOM is not by using the C++ components through XPConnect (which is used to access them from javascript). I don't suppose it does much of a difference anyway.

Well, XPCOM its nice except for the lack of good documentation (but you have Mozilla source code to look for examples). Its a good library, which shows an enormous effort, and covers the basics and a bit more. Even so, I did run into a couple of SEGFAULT, but I was guilty of all of them. For example, creating an object as an instance when it was service (a service is similar to a singleton, and should only be created once by the application), which was really easy to figure out looking at the code and seeing that it used some static variables, since the name of the component didn't include "service" in it, and services don't have any feature that distinguish them from instances. Of course, the SEGFAULT was created the third time I created the component, not the second, and without a warning.

Besides that, and the fact that the RDF DataSources components don't complain about anything and silently ignore content they don't understand, use an outdated RDF specification (or tell me if you heard of rdf:instanceOf/rdf:nextValue before...), and creates some awkward RDFs (<bar: rdf:type="foo">, maybe I'm wrong, but what is an XML element without a local name???),

You also have a lot of assertion failed messages from XPCOM and the Mozilla platform in general. But Mozilla keeps running nevertheless, so why would you give a damn about them if the platform doesn't?. At least they do have a nice and complete error reporting about unknown CSS attributes (some unknown to the platform, not the documentation).

I won't even try to talk about RDF templates (the standard XUL way to create dynamic content based on a RDF document). I did use them, and in fact, I liked them in the end ;). However they are limited in what you can do (conditional processing specially), and hard to learn. And of course, how to make them dynamic is also badly documented (uri attribute is ok, ref isn't).

Just as Gmail is now used as a way to show how you can do responsive and natural look&feel applications with HTML, both Firefox and Thunderbird are the proofs that XUL is also a fit to develop large scale client apps. By looking at Firefox I always said, I must be getting something wrong, this thing must be good, I must be understanding it wrongly. Later I realized that Thunderbird is not all that different in concept to Firefox, and that they are developed by the same foundation that develops the platform and core components (didn't check if by the same people). I'm not suggesting they are blinded by love to one's product, probably they obviously find it great, because they know intimately how it works, if they need a modification they do it, and I bet the platform also evolves with the needs of those and other Mozilla Foundation products. Its just that I don't see it fit for other large scale, "different that browser", developments.

Maybe Mozilla developers never intended it to be that way, but I think that XUL and the Mozilla platform is being promoted as something that its not. I didn't saw XAML yet, but I doubt that XUL will be able to compete with it in the rich thin/fat client platform niche.

Because its not general enough, because it hackish, because its too big for being documented from scratch, because XPCOM implementations are mostly in C++ (there are other options, apparently, but honestly I don't think they are being used intensively, otherwise Mozilla itself would start replacing that C++ codebase, kidding ;)), because javascript sucks and rich fat clients require more coding in the client side (and therefore more than event handling) and because a platform in which assertions are not enabled because they don't know if the assertions should really be there is just not reliable enough.

Its important for developers not only to have an enormous amount of content and features to play with, but also a standard way of doing common things. You shouldn't need to think about how to implement inheritance, or importing source files. Nor if you must implement an MVC by using commands, or calling actions from onclick events, or adding the onclick in the XUL instead of the .js, etc.. Sometimes this lack of flexibility (which I don't think its a lack at all) will just make programmers feel from the start they are doing it the right way, the way is intended to, because TOOWTDI (there's only one way to do it). That is, in my opinion, one of the purposes of a development platform also.

I'm sorry XUL, I did fight for you in this project (more than I should fought). I'm starting to work on eclipse RCP now, and everything looks fine at this time. Maybe Mozilla XUL is still the best option for a particular target (and I'm not implying it should be a silver bullet), but even in that case, I fear its just because of lack of competition than real product quality.

2 comments:

Anonymous said...

thanks for the article man. I am also considering moving our company's web based collection of application into more Rich Client Env. I looked at XUL and love Eclipse RCP, so your article helped. Now if I could only convince the management that RCP is the way to go...

Anonymous said...

136557 [b]Tag:[url=http://www.cheapraybanaviators1853.org/]ray ban sunglasses sale[/url],[url=http://www.cheapraybanwayfarers1853.org/]ray ban sunglasses outlet[/url],[url=http://www.oakleydiscountoutlet.org/]oakley sunglasses sale[/url],[url=http://www.oakleydiscountsunglass2013.org/]discount oakley sunglasses[/url];Links:[/b][url=http://www.facebook.com/]oakley sunglasses sale[/url]
they are well received and highly prized. Then they become one of the great innovations in sunglass sphere, so that they tend to be most widely used colour. and also their particular types and also designations are usually constrained both. They could probably fulfill the specifications regarding eyeglass wearers. The particular well-known sunglass brand name, pharmaceutical drug glasses which often merge this highlights of both equally pharmaceutical drug a pair of glasses in addition to glasses. There're in particular intended for these myopia exactly who ought to be outdoor typically. Many people eliminate the reduction of which eyeglass sports should have on for the purpose of as soon as to merely have on glasses.The way it is recognized to all of that at this time you will discover a bit of pharmaceutical drug glasses out there, there're connected with small sharpness. Thus there're acceptable for being utilized with inviting days to weeks but is not acceptable as soon as is driving a car; brown leafy pharmaceutical drug glasses will be able to hold journey glare indicate by different shiny exterior along with the wearers will be able to view photograph specifics, they're just for decreased sharpness. For this reason they're just perfect to generally be damaged during sunny days or weeks however is not perfect anytime you're cruising; red recommended eyeglasses are capable of always keep up from the glare replicate with many other glowing outside and also wearers are capable of look at appearance info, Rayban grasps ecommerce probability. A considerable amount of main individuals apprehensive are actually described as to researching the drawback who the simplest way to generate a particular eyeglasses which sometimes provide the wearers a definitive prospect not to mention eyeball insurance. Subsequent to 3 years' chores,

Our first Tuna (eduna) blog!

Thanks to the first blogger (outside netlabs:)) that mentions e-duna! .... Of course, maybe he's not the first, but he is the first we ...