code.flickr.com, Flickr Uploadr 3.0 and XUL

Flickr have just launched code.flickr, Your one-stop shop for information, gossip and discussion with the Flickr developer community which I imagine they want to use to draw together the disparate developer resources from the groups, forums, mailing list and more.

I guess they also want to use it to hire a new XUL guru because the author of their new Uploadr, Rich Crowley, has left and is now working for OpenDNS.

The new Uploadr does seem better than the 2.x version, and has some nice features, but none of them seem hugely critical. Last time I used it, it was unreliable, slightly slow and I read a lot of bad press so I reverted to version 2.x (I’ve just reinstalled v3 and I will give it another go).

But, it’s in XUL. I don’t like XUL. I started writing some crappy XUL applications at the beginning of the century, and it was *hard* (it didn’t help that the documentation was both partial and obscure). From what I understand, the situation has improved, but not to the extent where there’s an XUL development ecosystem outside of Mozilla extensions (covered in season 5 episode 1 of LugRadio).

So although it’s cross-platform, it’s written in C++ and specifically in a reasonably esoteric UI library, thus barring all but the obsessive from committing to the core. It can use extensions, which are written in C++ and/or JavaScript, but this doesn’t address what seems to be a major problem.

If cross-platform was an absolute goal, and Adobe Air is out of the picture, and bearing my current pastime in mind, it would have seemed more appropriate to choose wxWidgets or, for a web company like Flickr, one of the other language implementations like wxRuby or wxPython.

In summary: XUL, bah.

Published by

One thought on “code.flickr.com, Flickr Uploadr 3.0 and XUL”

  1. You’re right about the partial and obscure (not to mention frequently wrong) documentation on XULRunner but it does have significant advantages over competitors in the cross-platform desktop space. The ability to link custom native libraries (think GraphicsMagick and FFmpeg) and true multi-threading were my main reasons for choosing XULRunner.

    On top of that, the vast majority of the source code is actually JavaScript, not C++. Take it for a spin, it’s actually more inviting than you may think!

Comments are closed.