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

Count the occurrences of XUL in that summary.

[Anonymous Coward]

I get 8. Does anyone smell gratuitous name-dropping?

Re:Count the occurrences of XUL in that summary.

[bazmail]

I counted 12. (including the title and libxul as an occurance)

That is all.

[--END COMMUNICATION--]

Re:Count the occurrences of XUL in that summary.

[Acts of Attrition]

There is no Dana, only XUL

Re:Count the occurrences of XUL in that summary.

[henrygondorff]

Hehe... loved Ghostbusters!

Also worth mentioning

[Anonymous Coward]

PyXPCOM, for Python-scriptable XUL applications, should be available shortly.

XuulRunner

[hattig]

The platformisation of a web browser's interface libraries.

Good work - a true cross-platform API with full interface features and themability. Windows, Linux, Mac OS X, Solaris, ...

I should have a look at it someday, it might be an interesting platform for writing mediumly complex GUI applications. How is the development tool environment though? Whilst I like a terminal and build scripts, not everyone does, and mass uptake would be restricted greatly if there was no Eclipse/etc plugin.

As a platform, or part of a platform, how does it compare with Java, .NET, etc?

Re:XuulRunner

[misleb]

I should have a look at it someday, it might be an interesting platform for writing mediumly complex GUI applications. How is the development tool environment though? Whilst I like a terminal and build scripts, not everyone does, and mass uptake would be restricted greatly if there was no Eclipse/etc plugin.

You don't build it it. It is all Javascript and XML. So whatever tools you would use for that. What's an Eclipse plugin going to give you beyond syntax highlighting? What more would you need? I hardly see this as a hurdle.

I should have a look at it someday, it might be an interesting platform for writing mediumly complex GUI applications. How is the development tool environment though? Whilst I like a terminal and build scripts, not everyone does, and mass uptake would be restricted greatly if there was no Eclipse/etc plugin.

It doesn't compare, really. As it is uses Javascript, you are severely limited in the class libraries available to you. To do anything really useful (manipulating external data, for example) you kinda have to interface with a server using XMLHTTPRequest or something.

-matthew

Re:XuulRunner

[Anonymous Coward]

This is incorrect.

Privlidged Javascript in Mozilla is very capable and can have full read/write access to your hard disk among other things, through the XPCOM interface.

If XUL were really so limited, a little known application called Firefox, which is coded entirly in XUL & Javascript, could not exist

Re:XuulRunner

[Pneuma ROCKS]

As a platform, or part of a platform, how does it compare with Java, .NET, etc?

Compared to Java, it's significantly faster, because the back-end code is C++. Some argue Java can be faster than that on occassion, but I laugh at those arguments every time I start Eclipse or OpenOffice (you can disable Java on OO for a faster experience, BTW). As you said, it brings the worderful portability Java offers, with more efficient and flexible code. The XUL language is a very powerful interface development language that allows you to create portable UIs that can use the native themes of whatever desktop manager you're running on. Just see the differences between Firefox for Windows, Firefox for Linux and Firefox for Mac. It's the same code, but the look has subtle differences to adapt to each system.

Compared to .NET, it has the advantage of portability. One could argue that Mono takes care of that, but AFAIK it's far from being widely accepted. And again, XUL kicks their ass on interface development and management, and the javascript front-end scripting allows the creationg of new features and components without having to recompile or use heavyweight IDEs or debuggers. I use Textpad and the Javascript Debugger extension. Good enough for me.

I have great faith on the XULRunner project. I think they will accomplish what Java never could. It's just a matter of good programming and enough acceptance. People should give it a spin and see what I'm talking about. It could be the next big thing. Then again, it could only be a trend. What do I know?

Re:XuulRunner

[Anonymous Coward]

Wow. If you were any more full of shit you'd need a breath mint to take the smell off.

Re:XuulRunner

[misleb]

If XUL were really so limited, a little known application called Firefox, which is coded entirly in XUL & Javascript, could not exist

And this is the problem. With XUL, you're entirely limited to whatever the Mozilla developers found necessary to build a web browser/mail client. Don't get me wrong, XUL has a hell of a lot more rich GUI power than HTML, but it doesn't quite have the robustness of other application development platforms. If I were teh XULRunner team, I would be looking to ditch Javascript altogether and use something like Perl, Python, or Ruby to drive the XUL interfaces. Something with a little more client-side power. But I guess that would pretty much defeat the point.

-matthew

Re:XuulRunner

[starwed]

I don't think that's ever a direct problem. Javascript could certainly be a nicer language to work in, but it never prevents you from reaching your goal. It's not the scripting language that constrains you, but the underlying components.

However, it is actually possible to write your own components, even in C++, and distribute them along with the rest of your code. Obviously you lose some of the advantage of XUL at this point, but if it's just one small feature your missing you can code your own.

And of course as people start to use XULRunner, specific needs will drive further development. Things that Firefox doesn't need to do, such as query SQL databases, will have components written for them.

Re:XuulRunner

[Myen]

Actually, they're moving history &c to sqlite, so it'd have some sort of SQL like thing soonish :)

(If you build from the Mozilla source tree itself, it also has some other sort of SQL thing (/extensions/sql), but I've never quite figured out what it is...)

XULRunner future.

[Tei]

Even if Mozilla evolve to XForms base, will be posible to continue XULRunner as a separate project. So XUL is here to stay.

XUL is very good RAD tool. Much.. much much better than HTML. Because with HTML you sould care about styles and other miscelanea problemas, and becasue with HTML you badly emulate OS widgets, with XUL you use OS widgets.

Also good bonuses are easy to code with javascript, and the integration with XML (indeed!).

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.

Re:XULRunner future.

[jalefkowit]

Personally, I feels XUL's only achilles heel is javascript.

You're in luck :-) Python bindings are coming to XUL.

That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

Mozilla is working with ECMA on that too. See Brendan's comments about ECMAScript 4/JavaScript 2.

Re:XULRunner future.

[Senzei]

Personally, I feels XUL's only achilles heel is javascript.

Be honest with yourself here, how much of your experience with javascript involves those craptacular "this is how you do a rollover" tutorials? There are a lot of examples of people trying to use it like a real language, and when treated that way it is much nicer to work with.

Re:XULRunner future.

[bahwi]

XulRunner is what FF2 and TB2 are going to be based on, you'll have 1 XulRunner app and will install FF and Tbird, so XulRunner is here to stay. XForms will also be an extension available later.

Re:XULRunner future.

[symbolic]

you badly emulate OS widgets, with XUL you use OS widgets.

Well stated. I wish people who keep trying to create these faux css-based widgets would understand this. Compared to something like XUL, they look, and behave like cheap hacks.

Re:XULRunner future.

[FooAtWFU]

It doesn't help that Javascript is the world's most misunderstood programming language.

Re:XULRunner future.

[rpg25]

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

For me, in order for something to qualify as a tool for rapid development, it must have (at least) the following:

1. An interpreter, allowing you to experiment with code snippets by typing them and seeing their effect immediately.
2. A debugger. The importance of this can be minimized by the presence of an interpreter, if the interpreter can access important parts of internal state.

Does anyone know how these XUL tools stack up along these dimensions?

I bought a copy of MacFarlane's Rapid Application Development Using Mozilla when it came out, and had a whack, but gave up because it was too hard to grope my way to successful development with what was available at that time. I had a brief correspondence with the late Mr. MacFarlane, asking him essentially these questions, and his response was, roughly speaking, "No, there isn't good support for experimental programming, but it's coming." Has it?

To make the question more concrete: As a point of comparison, how does the ease of incremental development with XUL these days compare with your favorite of perl + Tk or Gtk, Tcl/Tk, python + Tk or WxWidgets, or Visual Basic?

Re:XULRunner future.

[kbrosnan]

Sorry but you are wrong. At best Fx 3 and TB 3 will be based on XULrunner. Fx 2 will be using a similar Gecko core to the one used in Fx 1.5 (Gecko 1.8.1 and Gecko 1.8) . The XULrunner work that is being done to make Fx a XULrunner app is being done on the trunk where Fx 3 and Gecko 1.9 will come from.

http://wiki.mozilla.org/Firefox2/Features

Re:XULRunner future.

[bsmedberg]

On the contrary, XUL does not use OS widgets. It does try to use OS themes to draw CSS widgets when practical, and generally does a good job of it. XUL widgets do have significant advantages over HTML widgets in that they knows what the OS theme is and can emulate that behavior very precisely.

Re:XULRunner future.

[mibus]

However when you get dynamic, XUL really shines. People go on about AJAX, but XUL offers a huge amount of potential.

The MAB is the only non-Mozilla.org XUL-based tool anyone seems to mention. Are there many others? I also think it has great potential from what I've seen, but the lack of applications after all of this time seems odd...

Re:XULRunner future.

[njyoder]

I think you need to emphasize a bit more how much XPCOM destroys the "rapid" aspect. XPCOM is one of the ugliest, most hacked-together APIs I've seen. Worse than the Windows API you criticize. What is Windows "Visual" code anyway?

Re:XULRunner future.

[mewphobia]

However when you get dynamic, XUL really shines.

How so? There is nothing inherent about xul that makes dynamic document generation easier. In fact, it's the same, using the DOM.

People go on about AJAX, but XUL offers a huge amount of potential.

Comparing AJAX to XUL is comparing apples to oranges.

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.

Care to elaborate? What is it about javascript that is so bad? What hassle? I find it to be one of the easiest object oriented languages.

Re:XULRunner future.

[ObsessiveMathsFreak]

How so? There is nothing inherent about xul that makes dynamic document generation easier. In fact, it's the same, using the DOM.

XUL, unlike DHTML, is build from the ground up to be dynamic. Working with XUL button tags is a lot handier than essentially hacking HTML input tags to be buttons.

Comparing AJAX to XUL is comparing apples to oranges.
Because? XUL is just AJAX with DHTML replaced by something saner.

Care to elaborate? What is it about javascript that is so bad? What hassle? I find it to be one of the easiest object oriented languages.

There is no "class" keyword. You have to use "function" to create a class. I could go on, but this really says it all right there.

Re:XULRunner future.

[mewphobia]

XUL, unlike DHTML, is build from the ground up to be dynamic. Working with XUL button tags is a lot handier than essentially hacking HTML input tags to be buttons.

Again, care to quantify this? If i want a button in HTML I use the HTML button tag. To handle the click event you either describe onclick as an attribute or add an onclick handler via the DOM. What's the difference?

The only things i can see making dynamic document generation easier are the stack tag (although only slightly, HTML has layers), using RDF to fill trees (which is debatable, seeing as RDF isn't the easiest thing to get your head around in the first place) and templates (which still need a lot of work).

Comparing AJAX to XUL is comparing apples to oranges.

Because? XUL is just AJAX with DHTML replaced by something saner.

Well, even ignoring the fact that DHTML isn't a spec, and assuming you mean HTML or XHTML, they are still are still aggregates of AJAX. Last time i did maths, or computer science, an aggregate is not the same as equality.

There is no "class" keyword. You have to use "function" to create a class. I could go on, but this really says it all right there.

Okay now you have to be trolling. C++, Smalltalk, Perl, LISP. Are these languages not useful? They don't use the "class" keyword to to create an object. Which, after all, is more important. Classes are nothing without objects.

In Javascript, you don't need to use "function" to create a class anyway, witness;

var myclass = {x : 5, y : 54};
alert(myclass.x + " " + myclass.y);

Hmm.. that seems to be another, better way of doing things! The instance and the declaration are the same thing! If you're going to trash a language on syntax, at least learn the language first. In fact, this little bit of syntactical sugar is one of the precise reasons why Javascript is so cool. How do you return multiple values from a function in C++? Create a class or object? In javascript, it's one line.

So seeing as those points are mute, please go on :) You might learn something.

Oblig. Ghostbusters

[shepmaster]

"There is no Dana, only Zuul."

Or, as the Wikipedia points out:

"There is no data, only XUL"

Re:Oblig. Ghostbusters

[Jugalator]

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

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

[smittyoneeach]

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.

OK, you correctly point out the fact that tactics matter more than strategy when we live and die by the quarterly report.

Now that the strategic investments in good infrastructure pay dividends, is it really necessary to force-feed any closed, OS-centric solution on anyone?

Re:This is what lost the browser wars

[Anonymous Coward]

I thought it was also a way of having cross-platform applications?

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

[Bogtha]

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.

Decent enough for browser plugins. Decent enough if you are building an application that is very closely related to browsing. I wouldn't choose it for building general-purpose applications, no.

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.

Well no, you might expect it to leave scope, if you assumed Javascript worked like some other language that doesn't support closures, but that's not the way Javascript works, so it's not supposed to leave scope.

Unfortunately for me, I've never figured out exactly WHAT the closure takes with it.

Richard Cornford wrote a decent explanation.

XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms.

I think that's an implementation detail rather than anything intrinsic to XUL itself. There was an experimental "KaXUL" to implement XUL within KDE and Konqueror a few years back, but I don't think anything came of it. As far as I know, there's nothing stopping a XUL implementation from rendering XUL applications with native widgets, it's just the people who built the only functional implementation chose not to.

Re:This is what lost the browser wars

[Anonymous Coward]

It's necessary because users demand "OS-Centric" solutions. Look at Mozilla -- totally unpopular until they started faking Win32 with Firefox. Look at the Mac platform -- despite their small size, users reject anything that looks too much like a "bad windows port". Look at Java .... etc etc etc.

Re:This is what lost the browser wars

[jlarocco]

OK, you correctly point out the fact that tactics matter more than strategy when we live and die by the quarterly report.

That would almost be as dramatic as you were hoping, if only "tactics" and "strategy" weren't synonyms.

Seriously though, I don't see why you're trying to make this about open and closed source software. Mozilla basically said to Microsoft: "Here, do what you want with our market share while we go do something else for a while." If Redhat stopped all development on their OS for a few years so they could work on a killer office suite, SuSe and other distros would be all over Redhat's market share. Or, more precisely, Redhat users would be all over SuSe and other distros.

Now that the strategic investments in good infrastructure pay dividends, is it really necessary to force-feed any closed, OS-centric solution on anyone?

Netscape used to have more than half of the market share. Right now, Firefox has less than ten percent. XULRunner has yet to break even, much less pay dividends.

Re:This is what lost the browser wars

[tetromino]

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.

I suspect that I am feeding a troll, but here goes...
Your comment is much akin to the following:

• C is a horrible language -- pointers are too hard
• Java is a horrible language -- I can't wrap my mind around object-oriented programming
• Perl is a horrible langauge -- regular expressions confuse my poor brain
• Lisp is a horrible language -- parentheses terrify me
• Python is a horrible language -- I keep on messing up the indentation

Bottom line: if you can't be bothered to learn the grammar of the language you are using -- hell, if you don't find learning new languages and grammatical concepts positively exciting -- perhaps software development is really not for you. You might want to look into becoming a manager.

Re:This is what lost the browser wars

[bogie]

"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."

Sorry but that sounds like sour grapes to me from an Opera supporter. Most firefox users could care less about open source. They use firefox because its Free, its more secure than IE, and it has a fantastic extension system. You'll note that Mozilla only enjoyed limited success and that things only really took off when Firefox was developed. Bloat, memory leaks, etc and all its simply a better browser than IE and Opera. Over time that may change but for now you'll just have to deal with the fact that the kludge that is Firefox is more popular than Opera for reasons other than OSS.

Re:This is what lost the browser wars

[bahwi]

Drama queen, you make it sound like WWII. No one died, and Firefox has come about finally. Before it was a code nightmare, want to add a button? Edit 15 files in several repositories just to get it to work. We'd have Netscape 4.2(You can call it Netscape 5 but that means nada), not the greatest thing ever. The tides are waning from IE now, things are returning to normal, and people are developing Ajax and (ugh, hate to say it) Web2 apps that are cross compatible. Things are far better now than when they were before.

Re:This is what lost the browser wars

[jZnat]

If Opera were open source and supported XUL/XPConnect/XBL, I'm sure it'd be a lot more popular (extensions from Firefox that work with Opera? Stop the presses!).

Re:This is what lost the browser wars

[NutscrapeSucks]

That was a typical slashdot substance-free reply.

If you look at XUL from a competitive standpoint, it maps most closely against Java/Swing, where one generally does not have to be overly concerned with object lifecycles and 'native objects' and memory leaks (not that you can completely ignore it, but in general there's less "gotchas" than there is with JS.)

I'm a big fan of Javascript as a language, but can totally understand why someone from an RAD app-programming POV would see it as a drawback.

Bottom line: if you can't be bothered to learn the grammar of the language you are using ... perhaps software development is really not for you.

No, the bottom line is that developers use something other than XUL to build apps. You can challenge people's manliness all you want, but that's reality -- almost nobody uses XUL.

Re:This is what lost the browser wars

[Bogtha]

Before it was a code nightmare, want to add a button? Edit 15 files in several repositories just to get it to work.

Let's compare: which do you think is more difficult?

1. Editing 15 files in several repositories to add a button.
2. Rewriting the whole damn thing, over the course of four years... and then adding the button in a few lines of code.

I don't know about you, but I'm tempted to say that #1 is easier.

We'd have Netscape 4.2(You can call it Netscape 5 but that means nada), not the greatest thing ever.

Yes, but we'd have it six or seven years ago. Don't try and say that the rewrite was a good idea because what we have after seven years of development is better than what we'd have had after one or two years of development. Of course Netscape 5 wouldn't have been a big improvement over Netscape 4. But it would have been a functional, cross-platform, open-source browser to compete against Internet Explorer with about 50% market share, instead of a non-functional mess with 0% market share.

Things are far better now than when they were before.

That doesn't mean things couldn't have been drastically better.

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

[NutscrapeSucks]

The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.
Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

I'm sure many people remember the line from mozilla.org -- "It's not a Browser, it's a Development Platform!!" Urg.

Unfortunately, Mozilla (aka AOL) did not understand the fundamentals of what they were getting into. "Development Platforms" are far less about capabilities and a lot more about Tools. It's just confounding that they sunk soo much effort into developing XUL, and then never released documentation, never released a GUI builder, never really built a community.

Even ignoring the overall irrationality of the AOL building their own GUI Toolkit, it's just totally bewildering that they only went 80% of the way there. If one wants to compete directly with Microsoft and Sun in the devtools market, you really have follow through, not just throw a bunch of code out on a FTP site and then wonder why nobody's using it. They really did throw away 50% marketshare with nothing to show for it.

Re:This is what lost the browser wars

[tetromino]

If you want to look at XUL from a RAD programming point of view... it closely corresponds to things like Python (with tkinter, PyQt, or pygtk), TCL/TK, Perl (with Gtk2::*) etc. Which is to say, languages and environments which have many of the same issues as Javascript (closures, forgiving syntax, various aspects of functional programming bolted on, and memory leaks galore if you don't know how to use weak references).

I personally would not call Swing RAD. In my experience, it's one of the slowest ways to develop a GUI -- but hey, maybe you are a much better Java developer than me.

Re:This is what lost the browser wars

[Bogtha]

Unfortunately, there's no JavaScript equivilent to "use strict" - I really wish there was.

There is, in a way. Everything you say in the first half of your comment can be mitigated by setting the javascript.options.strict Gecko option to true, which throws up warnings when you make those kinds of mistakes. Unfortunately, it can't just stop processing when it hits bad code like this because absolutely loads of pages out there make these kinds of mistakes in ways that don't actually cause problems.

Re:This is what lost the browser wars

[NutscrapeSucks]

it closely corresponds to things like Python (with tkinter, PyQt, or pygtk), TCL/TK, Perl (with Gtk2::*) etc

Not to mention VB6 [which lacks the functional elements but was plauged with the same reference-counting issues.] Of course, you didn't add "VB is a horrible language" to your list because, well, people have actually used it and agree totally. :)

I'm not a Swing programmer, so I can't comment on efficiency. Just competitively, if someone is creating something for "cross-platform", "network-delivered" local applications, Swing dominates that market, so that's what they should be targetting, not obscure python bindings and the like.

Re:This is what lost the browser wars

[00lmz]

You might want to try JSLint(documentation) by Douglas Crockford. It checks that variables are defined before use, and also checks for other common mistakes (you can read about them in the documentation).

Re:This is what lost the browser wars

[jackjeff]

Well, I have always been reluctant to criticize XUL because Firefox runs very decently, even on MacOS X. There are some GUI glitches on OS X, but roughly, it performs better than.. let's say QT apps in general.

Although XUL looks like a flawn design, it works decently enough to run Firefox despite the hacks you describe... And it has also a great advantage: plugins written for Firefox are platform-less. You would not care about this if you use windows or linux x86, but I let you imagine what a relief it is for Firefox users on minority platforms (linux ppc, macos X, etc.. )... You don't have to spend your time re-compiling things. Everything works without hassle... It's a great feature for (a minority of) end users!

Now, javascript is certainly not the only interpreted language in the world. It may have made sense to use it back then, because the browser had to have a Javascript interpretor built-in anyway...

but... if you consider adding another language interpretor in your browser is not a problem and intend to replace XUL, what approach would u choose? What would you choose to have develop a platform independent plugin system which can handle native GUI and all? Just curious... I don't have the feeling there are out-of-the-box OSS solutions like XUL. Am I wrong?

Re:This is what lost the browser wars

[zootm]

The major problem with JavaScript is that it's basically a Lisp/Scheme-like language with C-like syntax, making it prone to human misunderstanding. Add the fact that it was developed in what could only be described as "a rush", stopping only briefly to be quickly standardised (probably the only large step forward in the language's history), and you can see what's wrong with it. It was an admirable attempt, and it can be made to work in great, but the fact is that was just thrown together too hastily, and not enough thought was put into it first.

By contrast, the other languages you list are generally a bit better in that department. I'm not a fan of all of them (in particular C and Perl, the former because I believe it's only really useful for systems programming and I don't enjoy that, and the latter because it looks untidy and overly-random to me and I just never found the time to learn it), but they are all better examples of languages in general.

In particular the complaint of your post's parent — about closures — is fairly valid. The language has C-like syntax and no particular "hints" at having such an unusual and (in particular for those used to C-like languages) potentially-confusing feature. It's something that can have detrimental effects if you don't know what you're doing with it, and (more seriously), it's something that you can create accidentally if you have no knowledge of its presence. The semantics don't match very well with the languages it looks like, and the syntax doesn't match very well with the languages it acts like. Although once one is used to it it can be used very well, it's immensely confusing to people because of things like that.

Re:This is what lost the browser wars

[BZ]

> (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)

I'm sorry, but you have no clue what you're talking about. This bug was fixed on the Gecko trunk back in September 2005 (as in, 4 months ago). The fix will be in Gecko 1.9 (and Firefox 3). It _might_ end up in Gecko 1.8.1 (and Firefox 2) if the remaining regressions are resolved fast enough.

On a more general level, "IE sucks and has this bug" is not necessarily a reason not to fix the bug.

Re:This is what lost the browser wars

[starwed]

Even the guy who created it admits it was created too quickly. ^_^

JS, unlike Python, was a rushed little hack for Netscape 2 that was then frozen prematurely during the browser wars, and evolved significantly only once by ECMA. So its early flaws were never fixed, and worse, no virtuous cycle of fine-grained community feedback in the form of standard library code construction, and revision of the foundational parts of the language to better support the standard library and its common use-cases, ever occurred.

This is changing, finally. Great toolkits such as MochiKit and Dojo have been developed and disseminated (with docs and tests, even). I should also mention OpenJSAN.org as a welcome development. We can finally see the outlines of a standard JS library system. Of course, this space is young and necessarily fragmented. I will blog some concrete thoughts soon on how browsers can expedite the evolution of a proper standard library.

But what about the core JS language? It's not going to go away, or turn into Python. It needs to evolve, and to co-evolve with libraries that become standard. How can this all happen in relatively short order, and on the web?

As noted here before, I am working in ECMA TG1 with colleagues from Mozilla, Adobe, and Microsoft. Adobe's interest lies not only in ActionScript, but also in SpiderMonkey, which has been embedded in Acrobat for years.

Re:This is what lost the browser wars

[bahwi]

#1 is easier? Then you're stuck, there's no future, and you've reached end line. #2 sounds much easier when you mention this project is going to last for more than a few years, and at some point #2 becomes the only option after years of code-rot.

"but we'd have it six or seven years ago."

And IE 7 would have already been out, code rot would have destroyed Netscape/Moz, and IE would have their current market share, and Netscape/Moz would have 0%, instead of the 10%+ (depend on which figures you look at, 10% is conservative, I've seeing 18% a lot).

Not to mention, as an Open Source project, people would be incredibly bored and tired with editing 15 files just to add a single button to all the operating systems. Mac would've been dropped, and there would be a split between a Windows branch and a Linux brand, where the Linux branch would have been completed, Windows would never have moved forward, and again, we're back to square one.

I think you're looking at the best case scenario, and you need to base those in reality. Sure, a company who is paying a bunch of people will sometimes work with editing 15+ files for a single change(well, then again, Netscape didn't succeed by doing that, did they?)

Re:This is what lost the browser wars

[MikeFM]

So you'd rather have kept on having a choice between two crappy browsers than take the time to actually create something that doesn't suck? To make a leap sometimes you have to take a step back.

The real problem was that AOL bought Netscape and they didn't understand the market or the technology. They should have kept a team working on current-gen technology to keep up the fight with IE while letting Mozilla grow in the background with another team. They certainly had the money to do it - just not the brains to do it.

Re:This is what lost the browser wars

[RobertLTux]

just as a side point at teh same time Micrsoft was flat out bribing and or blackmailing isps to drop netscape.

Re:This is what lost the browser wars

[smittyoneeach]

if only "tactics" and "strategy" weren't synonyms

That's like saying "chess" and "go" are both games. Request you research the definitions more deeply, please.

Re:This is what lost the browser wars

[ttfkam]

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?!

Dude, I figured out what "var" meant back in 1995/1996. Coincidentally, that was around the time I first learned JavaScript. Where have you been?

You might as well write about the bugs inherent with using malloc in C without ever using free (and not using a 3rd-party garbage collector). Hey look! Memory leaks! Who knew?

Everyone who ever bothered to look it up, that's who. You remind me of Perl programmers that never heard of "use strict" in their Perl scripts. "How am I supposed to know what 'my' means!?!"

Re:This is what lost the browser wars

[ttfkam]

C-like syntax with C avoids human misunderstanding? Tell that to all the buffer overflow exploits out there.

I know C. I know JavaScript. You know what helped me avoid human misunderstanding? Learning the languages. Everything else is personal bias and hot air.

Re:This is what lost the browser wars

[NutscrapeSucks]

The real problem was that AOL bought Netscape and they didn't understand the market or the technology. They should have kept a team working on current-gen technology to keep up the fight with IE while letting Mozilla grow in the background with another team.

Didn't AOL buy Netscape to get this expetise? And Netscape told them "Oh, Screw Communicator v5. Eric Raymond told us that with Open Source(TM), this Gecko/XUL stuff will be ready in a year, and Microsoft is going down!!"

Honestly, I think AOL realized Nutscrape was full of shit pretty quickly and only kept them around because pending of the anti-trust $ettlment.

Re:This is what lost the browser wars

[Bogtha]

#1 is easier? Then you're stuck, there's no future, and you've reached end line.

That's a false dichotomy. You simply don't have to choose between being stuck with bad code forever and a complete rewrite from the ground up. If you have a crappy code base, you can rewrite it a bit at a time without giving up your entire market share in the process.

Re:This is what lost the browser wars

[Bogtha]

So you'd rather have kept on having a choice between two crappy browsers than take the time to actually create something that doesn't suck?

Please see my other comment. That choice is not necessary.

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:This is what lost the browser wars

[zootm]

I'm not so convinced. I realise that one needs to learn any language to be able to use it, but looking like one while acting like another is just plain misleading.

Re:This is what lost the browser wars

[ttfkam]

It's not like C was the first language to use curly braces. Also, Perl does the exact same thing as JavaScript in that you must scope your variables ('my' as opposed to 'var') and yet people still find time to complain specifically that JavaScript is not acting enough like C. At this point, C is in the minority.

Come to think of it, there are more things different between C and JavaScript than features in common. But if it makes you feel any better, just think of "var" as JavaScript's version of C's typed variable declarations with char, int, et al.

Hell, C would probably act the same way if you didn't have to explicitly define your variables at the beginning of your functions. And yes, I know that you can define variables anywhere in the function body now, but that was over 30 years after the initial version of K&R.

Stop holding C up as a paragon of computing excellence. It was a huge step up from assembly language and faster than other "high level" languages of the time. Nowadays we have more than 16K of core memory to work with, and most of us aren't working on kernels.

Re:This is what lost the browser wars

[zootm]

I'm not sure what post you're replying to, but somewhere in here I was complaining that I hated C. It's the fact that JS has C-like (by which I mean Java-like, C#-like, C++-like, etc.) syntax. I just feel there's implications of semantics (or lack of semantics) that just don't hold from using a similar syntax.

My personal preferred languages are ML, Python, or C#/Java (yeah, sorry about that last "double trouble" pair, but I got used to them and they're very good for large-scale stuff). I'm not sure I consider C (or in particular C++) suitable for many tasks these days, beyond systems programming (and even then, things like the Singularity project have shown that they're not even required to a huge degree there). They're certainly overused.

Re:This is what lost the browser wars

[MikeFM]

No, AOL bought Netscape to get Netscape.com which was at the time one of the number one portals in the world and which Netscape was somehow not managing to use to their own good properly.

What is the language?

[cerelib]

I have always been confused about XUL, is it a language in its own right or is it just a library/package for javascript or some other language?

Re:What is the language?

[Bogtha]

XUL is an XML-based language that lets you define a user interface for a program. You hook it all together with lots of things web developers already know - it uses Javascript, the DOM 2 Event model, extensions to CSS, etc. You can use it to build stand-alone applications with XULRunner, or extend existing XUL applications like Firefox.

Frequently when people talk about XUL, they mean the whole system that makes XUL work - which includes the Javascript, CSS etc. "XULRunner" doesn't "run" XUL, it takes the user interface definition files defined in XUL, and executes the Javascript, renders the CSS, etc, to make it all work properly. XUL is just one component in the grand scheme of things.

XUL: WIkipedia

[eltoyoboyo]

Here is the Wikipedia article on XUL. I could have used this link on the PERL 6 web site since the documentation on PARROT and PUGS are composed in XUL. This was my first introduction to the format. The documents opened in Mozilla, but not in IE. While the arguement has been made here that you should only use Mozilla, why alienate a huge chunk of users without helping them along? Also, if you are going to publish in XUL, do not assume the casual user knows what the format and reader is. The Filext.com site did not yet have a listing or recommended reader for the XUL files.

Re:XUL: WIkipedia

[Anonymous Coward]

Parrot is a stupid VM. Virtual Machines should be tiny. libparrot comes out at 8+ MB on Linux. 8MB for a freaking VM!! Then add the compiler and such... WTF are they thinking?!

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:Huh!?

[ObsessiveMathsFreak]

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.

I don't think XUL apps should really be used outside the browser. XUL is really designed to be an easy to program javascript frontend enviornment for clients. It should be a slim-client connecting to your main application on the server.

Re:Huh!?

[NutscrapeSucks]

> what's the advantage over just putting Firefox on your system?

API stability -- This allows you to distribute standalone XUL apps without worrying that the next .01 rev of Firefox will change the API and break things.

Re:Huh!?

[TobascoKid]

I don't think XUL apps should really be used outside the browser.

But the browser is a XUL app. So is the mail client. That's one of the main points of XULrunner - to make it easier to make stand alone apps that use XUL for the GUI.

Re:Huh!?

[osgeek]

If you don't configure to be run outside of the browser, then you're locked into only being able to use Firefox. That kind of defeats the portability aspect of it, since many Windows users just use IE and Mac users only use Safari.

Standalone apps

[flubbergust]

I've been waiting for something like this for a loooong time. I've been searching for a way to build my own apps with XUL but I havent found crap on how to set up something like that yourself. If anyone knows then please tell me. I wouldnt need that now though with XULRunner.
It would be better if Firefox and all the rest would use XULRunner too so there would be some consistance between the projects so it doesnt result in several versions of XUL and I have to have all of them installed at the same time.

Re:Standalone apps

[StonedRat]

I forget where I read this (somewhere on mozilla.org), but I think firefox will be using xulrunner at around firefox 3.0 sometime in 2007.

please no user installation

[nietsch]

Don't know much about xul, but the mention of automatic install gives me shivers. That little thing of most windows users having administrator rights by default does not need a rerun on other platforms that are more secure by default.
there should only be one way how software gets installed on a linux system, and that is through it's package manager.

And now, on to TFM...

Re:please no user installation

[boy_of_the_hash]

That little thing of most windows users having administrator rights by default does not need a rerun on other platforms that are more secure by default.

You don't need to be root to install software for the current user, even on Windows.

there should only be one way how software gets installed on a linux system, and that is through it's package manager.

XULRunner is a package manager of sorts.

Does anybody know if there are any plans for (eg) gentoo devs hook it into portage's build system?

Re:please no user installation

[TobascoKid]

XULRunner is a package manager of sorts.

Which is something that Linux and the wider FOSS community really doesn't need - yet another way to manage packages of software. You've got several distro level package manegment systems (deb, rpm, ports etc), language level package systems (perl, python, etc) and now platform level packages. Why can't XULRunner just tap into the base package management system instead of doing it it's own way?

It's hard to see how yet more package management is going to make things easier, for example what happens if I write a python app that uses XUL for the front end and some C libraries and native python libraries at the back? The python runtime and the C libraries are managed by debian on my system but by rpm on somebody elses, the native python libraries use python's setup.py and the XUL would be managed by XULRunner.

Re:please no user installation

[Anonymous Coward]

Linux package managers are typically organized around installing packages for everyone on the system and must be run as root. The Firefox/XULRunner installation model is about allowing users to install software without having root privileges. If XULRunner could hook into the native package manager to install non-root software it might be considered, but the fragmentation of the different linux market makes it difficult to consider that as a practical option. --bsmedberg

Re:please no user installation

[MikeFM]

It's a little ridiculous that Linux has so many package managers. Gentoo at least is doing something different so it makes sense to be a sepperate tool. Apt, Yum, etc are so similar that there is really no point in having alternatives anymore. Fedora is my distro of choice and I find it hard to understand why they've made yum their default tool. Even apt works better than yum. I like rug because it had a very clean user interface and worked quickly. It also had a very nice graphical frontend (Red Carpet) for people that like that sort of thing. I have to wonder when an obviously inferior product such as yum is picked over something like rug. You can time them side by side and rug is a lot faster. Yum is a little easier to use than apt (but again slower than apt) but rug doesn't make you suffer through as many oddities in it's design and it's commands are much more obvious than yum.

If there is something better in deb packages lets take that, if there is something better in rpm packages lets take that too, and make a single unified package format. Then lets apply the same process to apt, yum, rug, and whatever other package managers people are using and build a single standard the community can agree on. Package management is a well supported and very understood issue for Linux developers so there is no reason not to work things into a single standard. (Again things like Gentoo are different.) This would make life easier for all of us users, developers, etc.

Then a program like Firefox would have a standard package manager it could use on systems that supported it. Heck, make our package manager cross-platform friendly and let Firefox install it on Windows to manage their packages. No reason for Windows, Linux, OS X, etc not to all use the same package manager.

Re:please no user installation

[nietsch]

so instead of clearing up the fragmentation, they add their own package manager? Could this be a typical mozilla move: our way or the highway?

Re:please no user installation

[Forbman]

You don't need to be root to install software for the current user, even on Windows.

Actually, on Windows XP (SP2?), if you are in the wrong user permission group (i.e., Power Users), you can't properly install most software. It won't let you install apps in X:\Program Files, for example, because you won't be able to create directories or manipulate files in that tree. IT won't let you load stuff into X:\Windows or X:\Windows\System32, either. Yes, I was able to "install" some of the GNU utilities for Win32 (gawk), but I couldn't add the directory to the PATH environment variable, couldn't install it in X:\Program Files (or manually copy it to a folder there), or move gawk.exe to X:\Windows. Luckily, I knew the sys admins, and I got local administrator privs.

Just recently dealt with this, btw.

Re:please no user installation

[Forbman]

It's more along the lines of JAR/EAR/WAR files for Java web applications, not for Linux apps typically installed by tar/rpm/deb/whatever. Thus, the *cross platform* talk about XULRunner, because the same install file, like a JAR file, should be as droppable and runnable into a Windows/Moz platform as a ZSeries/Linux/Moz server, just like a good generic JAR'd app is droppable into Tomcat, JBoss, Weblogic, Websphere, etc.

Dev environment

[roman_mir]

I am working on a couple of extensions and I wish there was a dev studio, possibly an Eclipse plugin for xul/xbl/xpcom/javascript/css/rdf integration. With my extensions, which have a very small codebase, debuging is a completely manual process (not counting venkman, which is a good tool but still not powerful enough for my needs.) Certainly having a good design helps a lot, because most of the time it is clear, which component should be looked at. When I just started on the first extension, I didn't understand javascript enough to componentize, so after a while, I completely rewrote the code, because the single file with functions grew too much and any debugging became extremely painful.

I am also looking for a way to 'run' xul components without doing a full build, a visual studio perhaps, that could help with layouts and avoid all the annoying syntax errors. XUL itself is a markup language that is XML based and allows building visual components - dialogs, menues, buttons, tabs, grids, textboxes, etc. While you can open a half done HTML page in your browser and see what is going on, with XUL you have to build the package first and then you can see what's going on (an incorrect XML structure in this case will give you an error, XUL must be well-formed and valid.)

XPCOM brings other challenges. It is a native library of services/components that can be accessed from javascript (or possibly other scripts) and that extend the functionality of the script to include things like file management, access to preference storage, window manipulation, etc. But you can't just run a compiler to see if you are doing everything correctly, you will only get errors in runtime.

Actually, I think this is the biggest problem - all errors must be caught in run-time. Javascript, XUL, XPCOM work, XBL, everything can be built (there is nothing to building anyway, just packaging really,) but after the packaging errors have to be caught in runtime, and I think this is always the biggest problem for a programmer who is used to rely on compiler to quickly catch some of the problems before even starting the application.

Maybe there needs to be a unit-testing framework created, that can help running unit tests on portions of the code without building the entire application and catching unit errors during execution of the entire application. Yes, actually, to think about it this could be a big help, especially for the new developers, who can be put off this entire platform because of lack of these tools.

Re:Dev environment

[misleb]

I am also looking for a way to 'run' xul components without doing a full build, a,

Why can't you edit the installed plugin directly and just restart the browser to test changes? When i was writing my XUL plugin, I just used Mozilla to test and kept firefox running for actual web browsing?

XPCOM brings other challenges. It is a native library of services/components that can be accessed from javascript (or possibly other scripts) and that extend the functionality of the script to include things like file management, access to preference storage, window manipulation, etc. But you can't just run a compiler to see if you are doing everything correctly, you will only get errors in runtime.

Welcome to the world of developing with scripted languages.

Maybe there needs to be a unit-testing framework created, that can help running unit tests on portions of the code without building the entire application and catching unit errors during execution of the entire application. Yes, actually, to think about it this could be a big help, especially for the new developers, who can be put off this entire platform because of lack of these tools.

Writing unit tests (and keeping them up to date) is pretty tedious work. Doesn't really offset the pain of having to run the application to find syntax errors. But still, a unit testing framework would be useful for other reasons.

-matthew

Re:Dev environment

[roman_mir]

Why can't you edit the installed plugin directly and just restart the browser to test changes? When i was writing my XUL plugin, I just used Mozilla to test and kept firefox running for actual web browsing? - there all kinds of hacks, that one can do for this, but they are still hacks and not a substitute for a well thought out dev solution. It is possible to create various tools like syntax checkers, that could be run during 'compile' time.

Welcome to the world of developing with scripted languages. - thank you for welcoming me into it, but you are about 13 years late.

Writing unit tests (and keeping them up to date) is pretty tedious work. Doesn't really offset the pain of having to run the application to find syntax errors. But still, a unit testing framework would be useful for other reasons. - I do this tedious work at work every day, I would certainly do this for extensions as well if there was a standard framework for this.

Re:Dev environment

[Myen]

You might be interested in XPCShell (err, not sure if comes with the Gecko SDK and/or the suite; all I know is building Firefox yourself seems to make it). It's basically a XPCOM enabled JS shell. Of course, that means things like window are still undefined... that doesn't make sense unless you actually have a window :)

As for making up small bits of XUL, the extension developer's extension has a editor (it basically has a frame that loads whatever you type into a textbox in). Doesn't work too well with dynamic stuff (every time you edit, it reloads that window...), but is good as a quick syntax checker.

Re:Cause of death of Nigel McFarlane?

[mccalli]

And the feeling tells me something like this: "Did Microsoft pay someone to kill him?

For crying out loud guy, get a grip.

Cheers,
Ian

OK

[sabit666]

But where are the IDE's/GUI builders for XUL? Those `tutorials' sure don't help newbies.

Re:OK

[Anonymous Coward]

The GUI builders are the same place where good HTML builders are: emacs or a good text editor! Good web developers don't use wysiwyg HTML/XML editors. It is easier and more reliable to just know the markup language, CSS and preview in a browser.

Re:OK

[NutscrapeSucks]

And that explains perfectly why there are 1,000,000 VB applications in the world, and only 7 XUL applications.

"We're too l33t for GUI builders HUR HUR HUR!!!!11" (meanwhile 100 man-years of programming effort disappears into obscurity)

Re:OK

[srussell]

And that explains perfectly why there are 1,000,000 VB applications in the world, and only 7 XUL applications.

It also explains why all of those 1,000,000 VB applications suck ass.

--- SER

Re:OK

[Anonymous Coward]

If you use Windows, you already have the IDE installed. It's called notepad.exe.

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.

Re:Perhaps they could fix the installation methods

[Anonymous Coward]

I read your missive with increasing disbelief - at first I assumed you were engaging in hyperbole, then it turned out to be outright misinformation. You sound like you're going to take your little ball and go home if the world doesn't immediately twist itself to conform to you. It's pretty fucking pathetic.

My favorite bit from your diatribe:

      "To complicate things even further, the profile name is a randomly generated string, so some things will not copy as well as you might hope"

You make it sound like it's a randomly *changing* string. It's a static name... it's not like you have to hurry and grab your files before it changes again. If you're having trouble copying files because the sequence of letters that make up the directory name doesn't look like a word to you, your problems with browser plugins actually start making sense. Maybe computers just aren't your thing.

Re:Perhaps they could fix the installation methods

[Chemisor]

> You sound like you're going to take your little ball and go home if
> the world doesn't immediately twist itself to conform to you.

Why yes. If your application is as unfriendly as mozilla's plugin installation, you can be sure I am not going to use it. While it doesn't hurt me much, it will hurt you if you are selling it. In mozilla's case I'm only complaining because I can't just ditch it and use something else; there is nothing else.

> You make it sound like it's a randomly *changing* string. It's a static name... it's
> not like you have to hurry and grab your files before it changes again. If you're having
> trouble copying files because the sequence of letters that make up the directory name
> doesn't look like a word to you,

I'm sorry if I wasn't clear on this point. The problem is that configuration files under the profile sometimes store paths containing the profile name (like the Inbox path), so if you just copy all your data to a new profile, those paths would be invalid and you would have to reset them. Sure, it can be done, but a user-friendly application would not make a user go through so much trouble.

Re:Perhaps they could fix the installation methods

[HeroreV]

RTFA. The entire purpose of XULRunner is to run standalone XUL applications. Not to add bits of XUL onto something else. XULRunner has nothing to do with extensions. Your whining is completely irevelant.

Also, you need to stop referring to "extensions" as "plugins". They're completely unrelated and serve very different purposes.

Mod parent down

[ChrisDolan]

The parent comment makes no sense. Perl, Parrot and PUGS are documented in POD, not XUL. POD is short for "Plain Old Documentation" which is a Perl standard for marking up prose. XUL is a standard for laying out user interfaces. POD and XUL have nothing to do with each other.

Xoices

[Doc Ruby]

Whose idea was it to name "XULRunner"? Picking a name that's a new word, hard for most people to guess how to pronounce, is a bad way to get people to talk about it.

Re:Xoices

[MooUK]

It's easy to pronounce.

"Ex You Ell Runner".

Re:Xoices

[Doc Ruby]

That's a good guess. Since it's all one word, not an acronym (Ex Yoo El Ahr Yoo En En Eee Ahr?), maybe it could be "Chewlrunner", "Chulrunner", or "Zewlrunner", "Zuhlrunner" or "Schoolrunner".

The problem is not how hard it is to pronounce, but rather how hard it is to guess how to pronounce it. And "Ex Yoo El Runner" is fairly hard to pronounce, anyway.

Re:Xoices

[_xeno_]

It's "Zewlrunner". XUL = Zuul from Ghostbusters, that's why the namespace for XUL documents is "http://www.mozilla.org/keymaster/gatekeeper/there .is.only.xul".

Similarly "XPI" is "zippy" - the install technology used to distribute XUL apps.

Re:Xoices

[bsmedberg]

Mine... and I'm open to suggestions (sent privately please: contact info); in particular I would like a name that didn't have "XUL" in it, because the framework is just as capable of bootstrapping applications written in HTML or SVG as XUL; the framework also provides ways to embed web-page rendering in independent applications.

Re:Xoices

[Doc Ruby]

Well, since its a packager/installer for Mozilla apps, how about MoFo?

Good preview edition

[bahwi]

This is definately a good preview edition, we've been able to push through a release based off of this instead of using it as a firefox extension by using Advanced Installer which made MSIs easy for me. I'm sure any platform specific installer would be able to work as well, and we'll probably hang on to this for later MSI packaging once XulRunner has it's own installer(but once it does have it's own installer/upgrader we'll switch to that so we can run our stuff on Mac's again(and *nix, but that hasn't come up).

Download size

[Anonymous Coward]

The download size of XULRunner is larger than Firefox because firefox currently has an installer with optimal 7zip compression and the XULRunner developer preview is just packed in a ZIP. The installed size of XULRunner is smaller than Firefox and the future installer work for XULRunner should compress the archive comparably.

Apologies

[eltoyoboyo]

ChrisDolan,

I apologize for my unintentionally misleading statement. Parrot Does not have a XUL document. The intro to PUGS and HASKELL slides are XUL documents. They are both referenced from the PERL6 site. In my quest to find out more about PUGS and HASKELL I was thrown off course and had to learn about XUL first. There is no good purpose for that. A user should not be surprised by a new document format while on a quest for other information. And a fair question would be, where is the POD Perl 6 documentation? It is not on the site, nor is it on CPAN. I have not followed the project closely and as a casually interested user, the doc locations are not intutively obvious.

Thanks, E.

Re:Apologies

[MrDelSarto]

Do you have any idea what was used to make those presentations?

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?

Re:So what kinds of applications can one create?

[Photon Ghoul]

I know this doesn't answer all of your questions, but here are a few examples: http://developer.mozilla.org/en/docs/Category:XULR unner:Examples

Re:So what kinds of applications can one create?

[BZ]

> Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language?

Yes. And the hope is that soon you will be able to use JavaScript _or_ Python as the programming language.

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

The idea is that it should not. Some things are still not easily (or at all) doable without using C++, of course. Writing device drivers in JavaScript may not work, say. ;)

Mozilla & Eclipse

[kbrosnan]

Using Eclipse for Mozilla develpment http://developer.mozilla.org/en/docs/Eclipse

Memory usage?

[coldmist]

How much memory is chewed up by this to just diaplsy, say a 3"x3" square window, with a table and some text? For Mozilla/Seamonkey, it's something like 15MB. Same, less, more?

Also, like a browser, if you open a second "window", you only have a small memory hit to add the extra page (plus rendered objects). Is this the same here?

XULRunner SDK is in the roadmap

[bsmedberg]

I'd like to remind readers that this is preview release, and there are many aspects of this platform that are not complete, including a set of tools which will be packaged up as the XULRunner SDK. I am fully aware that you can't have a platform without excellent developer tools and documentation, and we're working to get all of those resources in place in the next year.

XUL App example

[blackhaze]

There need to be more examples of web-based XUL applications.

One is @Mail - A Webmail interface written in XUL for Firefox. It's coming close to a Web-version of Thunderbird. Take a look online at: http://demo.atmail.com/

Re:Presentations

[eltoyoboyo]

IMHO, looking at the text of the documents mentioned above, it appears that a stock header and footer was constructed and then the presentation script itself was done in a text editor.