Thoughts on XUL Runner

[I had deleted an earlier post for one reason or another on XUL Runner. I'm rewriting per a request]

I'm coming at this from a different perspective so what I'm thinking could be inaccurate.

Background 1

The evolution of XUL runner was based out of AOL being able to leverage the Netscape browser into the main AOL client. Basically one instance of the browsing engine should be on the machine and it could be leveraged by AOL, Netscape, CompuServe or whatever application that may need it. This kinda launched as GRE or Gecko Runtime Environment. One of the bigger reasons for this at the time was download size of the different applications. Of course that was in a still dial-up world in the year 2000.

In any case, AOL never embedded Netscape into their main client, it was tested and launched in the long defunct CompuServe client. It did work though.

Background 2

The modern thoughts on XULRunner came when the Mozilla Suite needed to be broken up into the separate applications. The thought was a Firefox or Thunderbird or Sunbird or whatever other applications that come up could leverage a single XULRunner instance and the download would be light, there would be shared components, and all would be happy.


There are three:

1) to do a XULRunner is hard, not easy building one of these and be able to predict what all the applications want, different versioning, etc.

2) The investment in XULRunner was minimal (just not a priority and if it's not Firefox who cares) and didn't get the chance to really get flushed out. Who was gathering the requirements? Who was talking to customers? Who was evangelizing the platform? Where were the white papers? It's still a project and maybe it will get it flushed out more down the road.

3) Possibly the biggest issue, no one is building client software anymore, none that matter anyway. You have two extremes, little shareware type applications that do one or two things that can be done using platform specific code. The other extreme is like an Adobe Photoshop i.e. some wickedly complex piece of software and you're not going to base Adobe Photoshop on XULRunner. Given #2, you're not going to get #3.

The interesting thing is that XULRunner is in direct competition with offline apps. XUL versus AJAX type offline apps would be a neat exercise to see what's good and bad about each. It's funny because we've had "offline" apps for the longest times, it's called n|VU and Thunderbird, and Songbird.

*I think this is what I said in the post deleted "XULRunner Pipe Dream" or something like that. I just whipped this up so I probably have more thoughts on this.

2 Replies to “Thoughts on XUL Runner”

  1. "XUL versus AJAX type offline apps would be a neat exercise"

    I has already been done. Its called Pow.

    For those new to POW, POW's core is the web server. In addition to being able to serve any file from POW, it also uses JavaScript (ECMASCRIPT) as a server side programming language and the final part is Sqlite as the database.

    And we have created XULrunner versions of it
    so you can host your AJAX apps on your desktop.

  2. From the article.
    "it's called n|VU and Thunderbird, and Songbird."

    This is so true. The blending of online-offline has already been done by the Mozilla extended team. They should take credit.

    From Scott:
    "For those new to POW, POW's core is the web server."

    POW goes beyond being a webserver to being a platform. You can create and entire XULRunner app, even using the database and file system, without knowing a lick of XPCOM. I hope this software inspires others to create a similar platform for all of the developers out there.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.