XULRunner Developer Preview Release Available

TeachingMachines writes "A stable developer preview release of XULRunner 1.8.0.1 is now available. Based on the Firefox 1.5.0.1 codebase, it is available for Windows, Mac OS X, and Linux. From the Mozilla Developer Center (beta): "XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. It will provide mechanisms for installing, upgrading, and uninstalling these applications. XULRunner will also provide libxul, a solution which allows the embedding of Mozilla technologies in other projects and products." Help with programming with XUL and its related technologies can be found at XULPlanet. Beginning programmers will benefit especially from the XUL Tutorial. Also check out the XUL Element Reference to get an idea of what's available. "

A couple of other resources are worth mentioning. First, there is the XUL Programmer's Reference Manual which covers interface elements for XUL version 1.0. "Rapid Application Development with Mozilla" is available for download at Bruce Perens' Open Source Series page. If you get the book, make sure to check out the errata. Unfortunately, the author Nigel McFarlane has passed away, so this is likely the final version. One final reference, "Creating Applications with Mozilla," is available here.

For those individuals who are looking for an extremely powerful application framework that is relatively easy to use, Mozilla is definitely worth a look.

Comments

This is what lost the browser wars

[Bogtha]

Back when the browser wars were in full swing and the Netscape source was just released, Netscape was at a huge disadvantage - they were fighting against Internet Explorer, which was bundled on every new desktop. However, they had an ace card - they were the browser of choice for ISPs.

Back when everybody was on dial-up, the usual way to get on the Internet was to get disks or CDs from ISPs, and run their installer. Typically, that also included Netscape, which was subsequently set to be the default. So while Microsoft had a browser installed by default on every desktop, Netscape was installed over the top of that for most people who signed up for dial-up service.

Then the Netscape source was released, and Netscape 5 was overdue. There was missing code, so it didn't build. Instead of filling in the bits that were missing, fixing the most prominent bugs, and releasing Netscape 5, practically everything was thrown away and they started again - to build a new platform based on Javascript and XML (and, oh yeah, with a browser I guess). XULRunner is the culmination of that process.

However, this came at a cost. Throwing everything away and starting again set back the development by a huge amount - it took over four years to go from the public release of Netscape's code to the first release of Mozilla. In the meantime, Microsoft released three new versions of Internet Explorer.

So what choice did ISPs have? Ship the outdated Netscape 4 to all their new customers? Ship a buggy prerelease Mozilla build to all their new customers? Pay Opera for every new customer? Or just bundle Internet Explorer? Of course they did the latter. The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.

So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough. But when I think of the stranglehold Internet Explorer has had on the market for so many years, and the pain that has caused me as a web developer, I can't help but think that the price was way, way too high for what is essentially just another cross-platform toolkit. Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

Re:This is what lost the browser wars

[Anonymous Coward]

So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough.

No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

First off, JavaScript. It doesn't matter if you can use XUL from other languages because parts of it are implemented in JavaScript. JavaScript is a horrible, horrible language. I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure. Lisp/Scheme developers know what a closure is. JavaScript developers probably don't. (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)

Unfortunately for me, I've never figured out exactly WHAT the closure takes with it. I know of no way to check the current environment to find out what your function accidently wound up keeping. However it does explain the "delete" keyword that had always confused me. Why do you need delete in a GCed language? Well, because without it, you can wind up with pointless variables that were supposed to be local that are accidently kept in a closure!

Next we have XUL and CSS. XUL isn't native - I think everyone's noticed that by now. Firefox manages to goof up the scrollbars, so they don't match my theme. They also goof up form controls, so that they don't match my theme. Under Windows, certain controls don't act like Windows controls. I'm told the situation is even worse under OS X, but I've yet to convince management that I need an OS X machine to test on.

Like you said, XUL was a horrible, horrible, horrible mistake. It should never have been made. They should have released Netscape 5 and worked on making a usable browser. Firefox is an interesting tech demo, but it's not something I'd want to support indefinitely. Quite literally the only reason people use Firefox at all over Opera is because it's open source. Were Firefox closed source, Opera would be the clear victor.

Yes, I know: XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms. Because of XUL, the entire core browser is a giant mess of CSS, JavaScript, XML, and XPCOM. XUL is an interesting concept, but it just fails in implementation. The insane hacks required to make XUL appear to be native are proof enough that it just isn't a smart design.

People often joke that Emacs is practially an operating system. With the release of XULRunner, Firefox has proved that it literally IS a complete operating environment. It contains all the libraries you need to write full applications. In a sane world, that would be called "bloat".

Re:This is what lost the browser wars

[Anonymous Coward]

Oh, please. JavaScript is just a horrible language, the discovery of the poorly-documented closures (how many people here knew JavaScript supposed closures?) was just the latest annoyance. JavaScript seems to be built from the ground-up to allow as many stupid errors as possible.

Let's start off with "var". WTF does "var" do?!

Well, it makes future variable references local to that execution context. Try this:

function foo() { i = 1; };
function bar() { i = 2; foo(); return i; };

What does bar() evaluate to? Why, 1, of course, because "i" is in the "global" context. Throw in a "var" before either "i =" expression, and then it evaluates to "2". Not surprisingly, accidently leaving out a "var" is expressions can cause some really interesting bugs.

function foo() { for (i = 0; i < 10; i++) { } };
function bar() { for (i = 0; i < 20; i++) { foo(); } }

Oops. I just created an infinite loop. Silly me.

Also fun is the fact that if a property doesn't exist, it just gets created, making the accidental typo undetectable until that code branch gets executed!

document.getElementById("something").style.dispaly = 'none';

Why is nothing happening? Oops. That's "dispaly" and not "display". I'll have to remember never to make typos, because it'll happily add the "dispaly" property and do nothing for me.

Now we get to the OO syntax.

function MyClass() {
        this.a = 1;
}

Yes, that creates a new class called "MyClass" that has a single property called "a" which is set to 1. Now we can add a function called "increment" to bump that up.

MyClass.prototype.increment = function() { this.a++; }

Yeah. That makes sense, we set a property on a "prototype" object off the function object. This effectively sets the property on all instances of the object - unless, of course, they're overwritten.

function Foo() {
}
Foo.prototype.myValue = 1;
var a = new Foo();
var b = new Foo();
a.myValue = 2;
var m = "a.myValue = " + a.myValue + ", b.myValue = " + b.myValue;
Foo.prototype.myValue = 5;
alert(m + "; and now a.myValue = " + a.myValue + ", b.myValue = " + b.myValue);

That, of course, displays "a.myValue = 2, b.myValue = 1; and now a.myValue = 2, b.myValue = 5".

Next we can look at the "this". WTF do I need "this" for? Because JavaScript first looks at the function execution context for variables (which contains "this", BTW), and then the global execution context. Of course. So this means that all member variables are always accessed with "this.", making OO JavaScript code look very messy.

Unless you use "with" which changes the context...

This is ignoring the JavaScript/XPCOM bridge class of bugs, which cause all sorts of memory-leak headaches because XPCOM is reference counted and JavaScript is garbage collected. Their solution to this makes it so that any XPCOM object that has a reference to a JavaScript object makes that JavaScript object a "root" object and therefore never GCed. Be careful passing JavaScript objects to XPCOM!

JavaScript is just designed to make creating bugs easy. Accidently make a typo, that's fine, it'll just create that new variable for you. It's like using Perl without "use strict" - something that most people quickly learn never to do. Unfortunately, there's no JavaScript equivilent to "use strict" - I really wish there was.

Re:This is what lost the browser wars

[xero314]

JavaScript is a horrible, horrible language.

Slow down and take a deap breath. There are no horrible languages, only horrible developers (or implementations). I happen to find ECMAScript to be a very powerful language. It includes dynamic prototypical inheritance, which is considerably more flexible and powerful than classical inheritance. It is fully object oriented, as everything is an object. True it is losely type, which can be both a benifit and a detriment, but that and the fact that it is interpreted are the only flaws I have ever found in the language. The JavaScript Implementation of ECMAScript even allows for individual objects of the same constructor to have seperate prototypes which aover comes the last issue I would have with the language, which is private inheritable object properties.

Understanding Scope in ECMAScript does take a little bit of learning, and its certainly not for everyone, but it's not a flaw, its a benefit, if you know how to use it. I wait for the day that there is a viable ECMAScript runtime environment not in a browsers for writing applications. XUL was a horrible, horrible, horrible mistake.

Just like JS, XUL is not horrible. The problem is that the current development is targeted toward getting Firefox to work. When more people develop in XUL you will seen it advance very quickly and become more stable and more powerful. It's atleast good enough for Microsoft to copy it in their XAML implementation. I happen to be pretty much against the idea of "Web Applications" but after having worked with XUL for a couple years I find that web apps may actually be a viable thing.

XULRunner is actually a good step toward getting rid of some of the bloat of Firefox and other Web Browsers. If we can take the Web Application out of the Web Page Browser and move it into the Web Application Browser, we can have two specialized programs and alot less bloat in both.

Re:Oblig. Ghostbusters

[Jugalator]

http://www.mozilla.org/keymaster/gatekeeper/there. is.only.xul ;-)

Huh!?

[blkros]

I thought "sweet!!!" now we don't need to have Firefox, or Mozilla on a system to run XUL-based programs (not that I don't love Firefox), but the download for XULRunner is bigger than the Firefox download. Why is that, is there extra stuff in the archive that actually isn't needed to use this, or what? I haven't really looked at it, but if all this is needed, what's the advantage over just putting Firefox on your system?

Re:XULRunner future.

[ObsessiveMathsFreak]

XUL is very good RAD tool. Much.. much much better than HTML.

I would classify XUL as a good GUI development tool. It's rapidity is quickly lost if one delves into any XPCOM backends.

However, for simple, client side, frontend GUI operations, XUL is a very, very useful tool. It gives you the ability of DHTML in a way that isn't a hack.

Here's a good example of XUL's layout capabilities. IN terms of pure layout, there not really that much here that is different from HTML. However when you get dynamic, XUL really shines. People go on about AJAX, but XUL offers a huge amount of potential.

Personally, I feels XUL's only achilles heel is javascript. That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

As a GUI application development tool, I would expect XUL and XAML to replace older methods such as GTK and *shudder* Windows "Visual" code. It's faster, cleaner, makes more sense, and you don't need 300 lines of code plus libraries to draw a hello world window.

Perhaps they could fix the installation methods

[Chemisor]

My nightmare story about trying to install mozilla plugins suddenly comes to mind. Until somebody things good and hard about these problems I wouldn't recommend anyone to write anything in XUL.

So what kinds of applications can one create?

[wordtech]

This sounds very promising and interesting--a robust cross-platform GUI-development platform. However, I've always been a bit baffled by the idea of Mozilla/XUL as a "development platform." It is so unlike the environments I'm used to (Tcl/Tk, AppleScript/Cocoa, Python/wxPython) that I'm not clear what one does with it. So here are some questions:

1. Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language? (i.e. is there finally a good reason for a non-web-dev to learn JavaScript?)

2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)

3. Can anyone point me to applications that already exist that make use of Mozilla as a development deployment platform? I'm already familiar with Firefox, Thunderbird, and Komodo. Are there any others? (i.e. that are standalone apps and don't run as Firefox extensions, say?)

4. What kinds of applications are *not* feasible with this development platform?