If you listen carefully to the Web 2.0 crowd, you will hear a disturbing undercurrent. They don’t just believe that the web is great. They believe that client applications are dinosaurs, dying relics of a programming paradigm that is irrelevant. I find this tendency alternately depressing and frustrating: not only is there a place for client applications, but it is a bright and promising future that can work in cooperation with the greatness of the internet.

Shaver is right: the web is great because it has fostered open cooperation, viral programming, coding by view-source, mashups and “being able to jam jQuery in the hole that used to have Prototype in it”. The internet provides an excellent medium for viral and open markup and programming. But this kind of programming does not need to be unique to the web, and the Mozilla platform is a great bridge between these two worlds.

Take a look at the Firefox extension system, for example. The extension system not only allows programmers to mashup the client, but it brings the world of view-source copy-paste development to the client in a way that is unprecedented. We can and should foster this same model of viral programming in client-side applications. This is the real power of XULRunner and the Mozilla platform, if we can tame and harness its complexity.

What does this mean in practice? The Mozpad (Mozilla Platform Application Developers) community has been working towards defining some projects and goals: I believe these goals should be evaluated in terms of their ability to bring web-style application development to the client. For example, a traditional “integrated” IDE is very poor at copying code from others and making it your own. If we really wanted to go down the IDE route (IMO we don’t) we should be thinking of features such as “I like this dialog, steal it” and integrated search for code patterns (from e.g. Google code).

Or, to take another example close to my heart, XULRunner application packaging. It is much more important to get a simple tool that can be used to package text files into an installer than worrying at all about compiling binary code. Binary code should be a minority and diminishing case in a viral-programming development model.

Even though Rafael Ebron claims that the rich client is dying, his point about offline web apps is important. The primary difference is of course the security and trust model: local apps have their run of the system and can perform complex network and disk activity (and install binaries if necessary), while offline web apps have to work within the bounds the browser has set out for them. Client apps are a complementary action for offline-enabled web applications, not direct competition.

I believe Mozpad should focus on the following high-impact investments:

• reducing the barrier to entry for developers (code and documentation);
• providing tools for viral programming (view-source, copy-paste, debugging and inspecting code)
• evangelizing the platform’s strengths

There is a bright future for client-side applications! We need to stay focused on the strengths of the Mozilla platform and the web paradigm and not be distracted by “RIA madness”, complex toolchains, or the need to imitate existing proprietary solutions.

Late last year, roc wrote about XUL Dark Matter: semi-private intranet or domain-specific applications that are using XUL. Mark Finkle and I are setting out to try and get an estimate of the size and needs of this community, and how changes to XUL (especially in the Mozilla 2 timeframe) could help or hurt them.

Next month Mark will be in Tokyo and I will be in Paris for the week surrounding the Mozilla Developer Days. I am very interested in meeting up with developers of these semi-private XUL applications. If you are or know one of these developers, please encourage them to contact me so we can talk.

Here are some of the specific questions I’m trying to answer:

• Why did you choose XUL?
• Why was HTML insufficient for your needs?
• If we added specific features of XUL to HTML, would you use HTML instead? e.g.:
  • Specific UI controls easily available
  • Templates
  • Overlays
  • Native Look and Feel
• How do you control the version of Mozilla your users view your app with? Do you have concerns about the future stability of XUL?
• Do you use XBL?

In June 2003, Mozilla version 1.4 was released. For the first time, the Windows installers of Mozilla installed two separate pieces: the Gecko Runtime Environment (GRE) was installed into a shared location on the user’s hard drive, separate from the application components. Standalone installers for the shared GRE were made available so that other applications embedding Gecko could use the shared runtime. Life was full of promise… until users started upgrading or uninstalling their applications. The nightmare unfolded gradually: unsuspecting users would install a new version of Mozilla and Netscape or AIM would stop working. System administrators would install one version, and users would install into a different location, and both installs would fail to work correctly. It was not uncommon for the computer to become so horked that no combination of running uninstallers and installers would fix it: the only solution was to go into the registry and manually remove offending settings.

To this day, the phrase “GRE” conjures visions of frustrated users, unhappy developers, and unreliable instability.

The Perils of a Shared Runtime

This is the peril of a shared runtime, and one we absolutely must avoid. It is fiendishly difficult to get right, and the consequences of getting it wrong are devastating for users and developers alike. In March 2005, I posted a vision of how a shared XULRunner runtime could be implemented sanely. It kept registrations of installed runtimes and applications, and made sure that the correct version of the runtime was always available to applications. The XULRunner roadmap referenced this plan for XULRunner 1.9 and Firefox 3. Time has moved forward and we are now making hard decisions about features that were planned for Firefox 3, throwing many away because they do not fit in the schedule. The shared XULRunner runtime is one of those features.

This is the long story behind Mitchell’s post about XULRunner investment and Firefox 3. Mozilla is not “killing XULRunner”. It is merely stating the (obvious, I thought) fact that the previously published roadmaps are incorrect, and reiterating our support for continued development of the platform.

What are we doing?

Even though Mozilla isn’t going to ship Firefox 3 on a shared XULRunner, it is continuing active support of the Mozilla platform and the XULRunner project in particular:

• Firefox 3 might ship a “private” XULRunner. A private XULRunner is a standard XULRunner build, but rather than trying to share it between Firefox and Thunderbird and other applications that might wish to use it, each application woulds ship and update its own copy independently. We have had a tinderbox building FF+XR experimental builds for months. The major tasks left to turn this on by default are mainly packaging issues to make it install correctly, and landing places-bookmarks. But Mozilla isn’t willing to let the Firefox 3 schedule slip for a feature such as XULRunner, so it may not make it in time. Developers who are interested in helping make this happen should contact me!
• Make sure that prepackaged XULRunner builds are available.
  • If Firefox 3 ships on top of XULRunner, the build process will produce XULRunner packages “for free” without requiring the Mozilla release team to do separate release work.
  • Otherwise, I will be working with interested developers to make sure we have contributed XULRunner builds. This may take the form of build machines provided by Mozilla on the community network, or build contributed from elsewhere. The Eclipse AJAX Tools Framework community is already creating contributed builds of XULRunner 1.8.1.x; this is a natural continuation of that process.
• Linux distributions will be shipping Firefox on XULRunner. Several Linux distributions are already shipping XULRunner packages by default, for use by Epiphany and other Mozilla embedders. These distributions have already indicated that they are planning on distributing a shared XULRunner package and building Firefox 3 on top of this package. This will reduce the maintenance burden of Mozilla security updates significantly.
• Continue to support the XULRunner ecosystem. XULRunner is being used in a variety of new and exciting applications. Mark Finkle and I will continue to work with developers using XUL and XULRunner to uplift appropriate features and code back into the platform, as well as solicit, consolidate, and publish documentation. XULRunner is nothing more than two files which bootstrap an application and hook it up to the Mozilla toolkit: contributed patches help make life better for all Mozilla developers, including Firefox and its extension ecosystem. Perhaps something like MozPad would be helpful, though I would really like to get as much of that documentation back into the Mozilla Developer Center as possible, for shared consumption.
• Continue development in Mozilla 2. Mozilla 2 will have a clean separation between the XULRunner platform and the applications built on top of it. Having a clean API separation and build system separation between components will reduce the barrier to entry of new hackers for both the platform and the applications built on top of it. Whether this means we will have a shared runtime, or simply have better tools for producing applications on “private” runtimes remains to be seen.

The Power of Openness

I would like to extend a special acknowledgment to Ben Turner of Songbird for his continued support and patching of XULRunner and of the Mozilla build system. He recently asked me “how can I help make the Mozilla build system easier to use for external applications?” This is the kind of question that makes me happy and lifts my spirits: there are some low-cost changes to our platform that could make everyone’s life a lot easier, and all you need is to send me an email or IRC ping. The XULRunner team is not “less that one developer”, but it is dozens of Mozilla Corp. employees, and hundreds or even thousands of developers working on the entire Mozilla platform. That I’m the only Mozilla Corporation employee working on nsXULStub.cpp is irrelevant, and a distraction from the accomplishments that we have all made together.