A Brief Introduction To XULRunner: Part 1

From Kodewerx

Jump to: navigation, search

Within this article, I will attempt to demystify Mozilla's XULRunner. For the sake of brevity, I will assume the reader is familiar with current standard web technologies; mainly HTML, CSS, and JavaScript. The target audience for this article is the common hacker looking for a way to develop cross-platform applications. I will begin this introduction with the "What" and "Why" of XULRunner, take you through an example "How", and finish with a few words of wisdom.

Contents

What is XULRunner?

XULRunner is the name of a platform (framework) developed by Mozilla for their flagship web browser, Firefox. [Note: anachronism! XULRunner used to be called GRE, the Gecko Runtime Environment. And before that it was called XPFE, the Cross Platform Front End. It was developed by Netscape for their flagship web browser, Netscape Navigator.]

The best analogy to explain XULRunner is to imagine the Firefox web browser, stripped of its user interface. That means, Firefox without anything the user can see, touch, or interact with in any way. On the surface, this sounds like Firefox just goes away in a *poof* with a press of the delete key. But really, that's all the "Firefox" part of the application is: the user interface. The hidden engine that makes it all come together as "Firefox" is XULRunner.

What Makes XULRunner a Platform?

XULRunner is kind of like Java. Some of the main differences are subtle, but important; Java is the name of a virtual machine (Java byte code interpreter), the name of a framework (a huge library of programmable objects and classes), and the name of a programming language. XULRunner is a bit like Java's VM and framework in one package.

XULRunner is also kind of like the .NET framework. The .NET framework is also a VM, like Java. And .NET is also a framework of objects and classes, again like Java. One thing that makes .NET different from Java is that .NET is not a programming language; .NET programs are typically written in the C# language.

However, XULRunner is not .NET, and it is not Java. The main thing that XULRunner shares with these technologies is that it is also a framework for cross-platform application development. In some ways, it even competes directly with .NET and Java.

How Does Firefox Fit into the XULRunner Equation?

Since version 3.0, Firefox has been built directly on top of XULRunner. This is not exactly how Mozilla envisioned XULRunner would be used, though. The original idea was to release the XULRunner runtime. And then at the same time, release XULRunner applications which would use it. Some of these applications would be Firefox, Thunderbird, Songbird, etc. Similar to the way which Java and .NET programs are released!

Sadly, XULRunner is not yet mature enough to make this a reality. So instead, XULRunner is "privately" included with Firefox, Thunderbird, and Songbird. This does bring one small advantage though: If your target audience has Firefox installed, they won't need to install XULRunner separately nor will you have to include the full 10MB XULRunner runtime in your application. Your users can just run your application using Firefox's XULRunner.

That's Fantastic, Really. But What the Heck is it?

OK, here's the straight-up truth in as few words as I can manage: XULRunner enables application developers to write rich-GUI programs that run on every major operating system, using languages and technologies that web developers are already familiar with.

That means, you write your GUI in a structured "language" based on XML; it looks a lot like XHTML.

Then you make your GUI pretty with CSS.

Finally, you give your GUI functionality with JavaScript.

Wait, You Mean My Program is Written in JavaScript?!

Kind of. At least, the parts which connect directly to your GUI are written in JavaScript. If you want, you could also write most of your program in C++, and call your C++ object methods from JavaScript.

The technology that enables JavaScript to talk directly to C++ is called "XPConnect". XPConnect also allows JavaScript to talk to Python, Java, and many other XPConnect-enabled languages (meaning someone actually wrote an XPConnect bridge for those languages).

XPConnect is great to get your code out of JavaScript land, for example if your have to run a really tight algorithm that needs as much speed as it can get. But XPConnect presents a lot of additional overhead. For one thing, all of the function arguments that you pass between JavaScript and C++ must first be converted by XPConnect into data structures which will make sense to the language on the other side of the fence. So, calling in and out of XPConnect can be very inefficient.

Oh, So Why Would Anyone Want to Use XPConnect?

Because it allows you to do things that ordinary JavaScript cannot! For example, JavaScript has no concept of file I/O. But C++ does. Writing an XPCOM component in C++ to do simple file I/O operations can effectively give JavaScript a means to open files for reading and writing, and doing other similar things like directory traversal. This is how JavaScript is capable of being used to develop real-world desktop applications; XULRunner contains a lot of these XPCOM components by default. File I/O and directory traversal are included out-of-the-box, for instance.

Hey, Slow Down! What's this XPCOM Thing, Now?

XPCOM is the Cross Platform Component Object Model. Without getting too technical and knee deep in new acronyms and jargon, XPCOM is the general catch-all term for everything on the "other" side of the XPConnect fence. XPCOM is a strange and mysterious land that we will explore in a later adventure. For now, you can think of XPCOM components as a .DLL on Windows, a .SO on Linux, and a .DYLIB on OS X; it's really just a dynamically linked library, wrapped in an enigma.

Alright, So You Mean My Program Still has to be Written in JavaScript?

Pretty much.

But all is not lost! JavaScript is really a wonderful and extremely powerful programming language. It's not just a simple scripting language that makes web browser users' eyes bleed. When used properly and responsibly, JavaScript can be coaxed into building things like, well, Firefox! And pretty much every add-on extension for Firefox, or even your own full-fledged application.

JavaScript is also a lot faster than you might think, starting with XULRunner version 1.9.1 (which Firefox 3.5 is based on). The technology within XULRunner that makes JavaScript so fast is called "Tracemonkey".

Why Use XULRunner?

There are a lot of reasons to use XULRunner over, say, Java or .NET. And there are also reasons to use it over simpler cross-platform toolkits like GTK+ or wxWidgets. There are also reasons against using it, as you will see. I will try to explain some of the advantages and disadvantages faced by today's XULRunner application developers.

XULRunner vs. Java/.NET

Compared to .NET, XULRunner and Java both have a significant advantage in pre-existing platform deployment. Almost every computer system in the world has Java installed. With Firefox being one of the most used pieces of software ever, that puts XULRunner second in line behind Java. And finally, .NET support is available almost exclusively to Windows users, but its true deployment is likely far fewer in number than either Java or XULRunner.

Java's user interface support just feels like ... Java. Rarely does a Java program ever look or feel like any other native piece of software on any operating system. And .NET programs look and feel like Windows programs, even on other operating systems.

By contrast, XULRunner tries to mimic the native operating system GUI as closely as possible. That means it does not use 100% native OS widgets (and it would never work like that! Remember, XULRunner applications are styled with CSS) but it does make an attempt to look and feel exactly like a real OS GUI.

Java and .NET use statically compiled byte code interpreters, meaning the application's source code is compiled before it can be used. XULRunner uses JavaScript, which is scriptable and never needs to be compiled. This can make development times very rapid. It can also make JavaScript interpretation slower than either Java or C#. Recently however, Mozilla has been working on making their JavaScript implementation run with Just-In-Time (JIT) compilation, to produce very efficient (and very fast) JavaScript execution in native code. That means JavaScript is recently a whole lot faster than it used to be (this is new in Firefox version 3.5, Tracemonkey is its JIT compiler).

XULRunner vs. GTK+/QT

GTK+ is a very popular cross-platform widget toolkit which is totally native to the GNOME Linux desktop environment. So every GTK+ application feels right at home to a GNOME user. KDE users won't be too thrilled to find that GTK+ applications don't fit in with their QT-native desktop environment, though.

QT is the cross-platform widget toolkit that is native to the KDE Linux desktop environment. Interestingly(?) QT apps feel right at home on KDE, but feel out of place on GNOME.

GTK+ and QT are not limited to Linux; there are ports available for Windows and OS X, as well. GTK+ is fairly skinnable, so it can be themed to resemble native operating system GUIs. But some times it just doesn't "feel" native. The same could be said of QT.

XULRunner vs. wxWidgets

wxWidgets is a native OS widget toolkit written in C++. Almost all widgets provided by wxWidgets are native to your OS. They will look and feel right at home no matter where you run your application (if you can build it to run anywhere, that is). However, some operating systems do not provide all types of widgets that wxWidgets supports. Such widgets will be "emulated" with non-native widgets.

On Linux, wxWidgets always uses GTK+, even under KDE. So it will have the same problems as running a GTK+ app in a KDE desktop environment. XULRunner also only uses GTK+ under Linux.

That Doesn't Help Much. I Need More Persuasion!

That's cool. This gives me the opportunity to explain some of the advantages to XULRunner that you will not find in the other application frameworks discussed.

First of all is extensibility. Think of Firefox extensions: An extension is simply a very small XULRunner application that hooks itself into the "host" XULRunner application; Firefox. There is very little difference between a full XULRunner application like Firefox, and an extension for a XULRunner application. This makes the extension developer documentation great for XULRunner application developers, and vice-versa. This also means that anything your XULRunner application can do, can be done by an extension.

Hypothetically, if a user of your XULRunner application wrote an extension that you really liked, you could integrate that extension into your application as a standard feature. This is how a lot of experimental features are done for Firefox, even. You could also pull out a feature that you think really doesn't belong in your application core, and make it an extension only, so that users may optionally install that feature if they want it.

Another nice thing about XULRunner is its ability to be skinned and themed. If you are writing a digital audio workstation, and want to keep your application within the mood of other DAWs, you might want to make a totally custom theme for it that looks nothing at all like the native OS GUI. Media players often do this as well. Then there's the option of making your program look even MORE like the OS GUI, by slightly tweaking the default widget stylesheet to more closely match other native applications.

Internationalization and accessibility! (i18n and a11y) Even if you don't need these features, someone out there might appreciate them! You might have had experience with a program in the past which was written in a language you do not speak. Wouldn't it be nice if you could open that program in a text editor and run all of the user-facing text strings through an automated translator? You could potentially make that program readable and usable in about an hour, depending on how much there is to translate. But this usually isn't the state of things. Most programs are compiled with only one language. That makes them difficult to modify, and also makes them nearly unusable to anyone of a different nationality.

With XULRunner, your applications can be built from scratch with i18n awareness, and they really can be easy to translate. It's a similar story with a11y; visually- and hearing-impaired users should be able to use your program with screen readers and visual feedback.

Scriptability!!! If you wanted to automate some complex feature in your application, you can just tie those features together with JavaScript. Even let your users write their own little scripts to automate tasks or extend the application's usefulness for themselves. The best part is, this is totally free to you: full JavaScript support is already included, so why not make it user-facing?

OK! You've Convinced Me!

Good. Read on! :)

How to Use XULRunner

Continue to Part 2.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox