XUL/Mozilla vs Eclipse RCP as a development platform

I was very close to an interesting experience around Mozilla/XUL and Eclipse RCP as a development platform.

The requirements were to build a rich client application that needed to run in a Linux box (probably 10s or 100s of Linux boxes).

Basically, the rich client needs to get an XML file with a form definition, get the data from the user, and post it back. The form definition XML is generated in runtime and it could be different each time for each user.

XUL + Mozilla looked like a good idea, so they generated the XUL file that was rendered by Mozilla and the data was posted back using RDF, as XUL has good support for it. I liked the idea.

The first issue they run into was that is not easy to load dynamically generated XUL remotely. I’m not sure if it was because they needed to sign it dynamically or because as there was no code-signing for XUL in Mozilla, they end up modifying the Mozilla code to be able to do it. That was not a big issue, because the clients boxes can have any software they want, so they could install the patched Mozilla.

When they started to move forward with the development, they began to suffer from dynamically-typed-language syndrome. To work with XUL you need to code in Javascript. A lot of javascript bugs are found in runtime, and that’s not a good thing. As there isn’t an easy way to unit test XUL/Javascript code, they resigned to that, and wrote code very very carefully.

They also suffered from the lack of documentation. There’s no good documentation on Mozilla XUL and they spent a lot of time solving issues like focus handling, trying different workarounds for things that did not make sense.

After some work, the XUL part was working OK. In the middle, they decided to build a part of the application as a Java web application instead of a rich client application, because it was an acceptable solution for the customer and it was much better to code in server side Java than in client side Javascript ;).

The communication between the client and server was going to be HTTP  + RDF. As XUL and Java have good support for it, it seemed simple. However, XUL implementation’s is based on a RDF version that was not the final specification, so they needed to tweak the Java-produced RDF so XUL could read it.

At some moment they needed to build an interface to a VOIP client process that was going to be running in the same box. So, they needed to have some code in Mozilla that talked to that process using sockets. The problem they found is that in Mozilla everything lives inside a window. When you close a window, all the objects created are gone, so there’s no way to have a ‘global’ instance and keep it alive forever.

At that stage, they decided that they should abandon the XUL approach and start over.

They evaluated a couple of solutions. One was to build it using Python. They like it and are very experienced with it. The other was using Java + SWT, and I suggested them to try the Eclipse Rich Client Platform.

They started with a barebones SWT solution to check how hard it was, and they found it easy enough. Then they started using the Eclipse RCP, and they loved it. The documentation is still lacking, but there is a lot of documentation around Eclipse plugins, and a lot of sample code, so they were able to move fast. Additionally, they are using the same RDF parser in both sides ;)

I learned to not to underestimate the value of a platform XUL looks really cool, but it’s actually a platform built for internal consumption by the Mozilla team, and is not a general purpose platform.

Eclipse looks better, however it’s still not a general purpose platform, but it looks that it will work for this scenario. I’ll know in a couple of months.

UPDATE: Now you can read about this from the real developer who suffered it.