

Firefox: An Acceptable Cross Platform GUI Toolkit - ynniv
http://ynniv.com/blog/2009/01/firefox-acceptable-cross-platform-gui.html

======
randomwalker
_Firefox seems like an obvious option for desktop apps. Yet it hasn't caught
on, and I'm not sure why._

Isn't it obvious? XUL is slow as _molasses_ compared to GTK (or anything
else.) There _are_ desktop apps written on top of Mozilla. Miro is one that I
use every day. I know the pain.

The perceived speed of Firefox itself depends mostly on the speed of web-page
rendering, and not so much the chrome. So I guess Mozilla's focus has been to
improve rendering speed, whereas Firefox's preferences dialog still reminds of
me of trying to use Netscape 6 on a machine with 32 megs of memory back in
2001. Oh, the horror.

~~~
iofthestorm
I agree. XUL isn't that bad, but it seems like XUL based applications use
about twice as much RAM as their non-XUL counterparts. Firefox and Thunderbird
are fairly competitive on that front with other web browsers, but Songbird
easily uses over 100MB of RAM, and is sluggish, whereas even Windows Media
Player, which for some reason has a reputation of bloatedness, uses under 30MB
on my machine unless playing video, which Songbird can't even do.

That said, I think one of the advantages to XUL is that it allows for easy
modifications and extensions. On the Firefox/Thunderbird front, that's worth
it, but in some other cases, it might not be. I think even Amarok on Windows
(when it works) uses less RAM than Songbird on Windows.

~~~
anewaccountname
>Windows Media Player, which for some reason has a reputation of bloatedness

The reason is that when it came out it was competing with WinAmp 1.x which was
the antithesis of sluggish.

------
lallysingh
Ugh, I hate normal cross-platform toolkits. Different platforms do different
event, layout, rendering order, etc. etc. etc. You can't map closely back to
native L&F without getting that stuff right. And if you get it right on one
platform, you've chosen to get it wrong on all others.

Cross-platform toolkits have a certain 'uncanny valley' of their own in this
respect: only instead of rendering quality, it's native widgets. If you don't
do native widgets, you're not going to look right. I have yet to see a toolkit
do its own widgets that look like the originals.

------
llimllib
Which, of course, begs a link to jerf's critique of this idea:
[http://www.jerf.org/resources/xblinjs/whyNotMozilla/index.ht...](http://www.jerf.org/resources/xblinjs/whyNotMozilla/index.html)
. Have things changed since then, or are his complaints still valid?

I, for one, am too scared of the wicked complexity and large memory overhead
to try developing a XUL-based app. But I've only done a Hello World.

~~~
jerf
I'd further add that in the time since I wrote that, where XUL has crept
forward, GTK and especially QT have _blazed_ forward. XUL just isn't remotely
competitive unless your app looks like a web app, in which case, it probably
should be a web app. The range where you need something that looks like a web
app but isn't one, and absolutely positively won't ever need any of the extra
functionality the other toolkits offer (all of which is there for a reason) is
a pretty narrow one.

Between bindings and scriptability built into some of the toolkits such as QT,
there's almost nothing left unique to the XUL platform. You can see an example
of that in [http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-
the...](http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-
dimension-wolfenqt/) around 2:40, where the script driving the little Nazi is
actually the scripting language QT ships with based on Ecmascript.

------
sc
why (the Lucky Stiff) was using XUL for Hackety Hack[1], but wasn't happy with
Mozilla, so he started building Shoes[2], instead.

[1] <http://hacketyhack.net> [2] <http://shoooes.net>

------
nickb
After all these years of development, Firefox on a Mac still doesn't feel like
a true Mac app. Text fields, for example, still don't work like Cocoa text
fields.

So all this portability comes with a steep price of never really having a
superb UI on your target platform.

Take a look at Songbird... it's been in development for many years and a lot
of that is due to XUL. I'm pretty sure that had they chosen native widgets on
each platform (GTK/Cocoa/MVC), they would have finished it faster and had a
much better product overall.

But the lure of "write once, run everywhere" is an everlasting dream that
almost never comes to a realization. Take Java for example... it still has
platform specific quirks.

~~~
est
> GTK/Cocoa/MVC

Did you mean MFC?

~~~
nickb
Yes, sorry. Haven't used MFC in a long time so it was slip.

------
old-gregg
We use some XUL for our project and I wanted to clarify something here.

First, there is XULRunner and then there is bare metal XUL. XULRunner is a bit
bloated and somewhat slower. If you want to go faster, then start from
scratch. Second, you can't compare XUL to Qt/GTK simply because XUL is
interpreted, not compiled - write once and run everywhere, for real. This is a
huge advantage.

Regarding execution speed: XUL is JavaScript and is getting all these latest
performance improvements we've all heard about.

And finally, unlike AIR, XUL can call native code fairly easily, so nobody
stops you from including Win32, GTK or Cocoa components inside of XUL
containers. Moreover, you can host Flash (we do) inside of XUL if you need
multi-platform animation, video and other stuff Flash is good for.

Two reasons, I think, XUL is somewhat obscure is because all desktop
development hasn't been exactly a hot topic in tech media lately and due to
somewhat steep learning curve since XUL is essentially a supercharged
HTML+JavaScript for desktop.

We also researched other options:

GTK doesn't really live well outside of Linux: it's Mac version is only
starting to take off and it has stability issues on Windows.

AIR has very limited integration options with native OS. Can't even call a DLL
if you need to, thus it's not really a desktop platform, but rather "Rich Web
Platform".

Qt is also an excellent choice if you have an expertise of building/packaging
C++ on multiple platforms, we picked XUL because of the ease of Flash hosting.
Qt didn't support Netscape-style plugins at the time.

------
latortuga
I actually work for a startup who's flagship application is written on top of
xulrunner. I'd say some of the complaints here are valid, it is at times slow.
However, we do have the advantage of the future integration of tracemonkey!

Also remember that xulrunner apps become instantly cross-platform because of
their nature - think of all these other apps that you're comparing to and
ensure you take that into consideration. Is Windows MP cross-platform with all
the same features?

------
SwellJoe
The eMusic download manager is built with XUL, and works nicely on Linux,
Windows, and Mac. I think it's pretty swish. I reckon if I _had_ to make a
desktop UI, I'd probably try out XUL.

------
mgk
celtx - www.celtx.com - a media making app, is built on top of FF (just about
to be ported to the 3.* code base).

~~~
jawngee
Do you work on Celtx?

------
bprater
Hey, what about Adobe AIR?!

You get two toolkits for free -- standard HTML and you also get Flash/Flex.

(BTW, if you want to hack apps that look like true client-side app in HTML,
check out the ExtJS kit. Amazing stuff. Well thought-out JS.)

~~~
omouse
Adobe AIR is proprietary. You could also use JavaFX or plain old Java. It's
under a GPLv2 or CDDL license.

(Some people care about free software, others don't. Just thought I'd mention
an alternative)

~~~
marketer
Actually, the flash platform is largely open source. The AIR framework (along
with the rest of Flex) is open source. See
[http://opensource.adobe.com/wiki/display/flexsdk/Get+Source+...](http://opensource.adobe.com/wiki/display/flexsdk/Get+Source+Code)

The AIR compiler is also open source. The only thing that isn't open source in
the stack is the flash player runtime, which executes the resulting SWF file.
However, the SWF file format is open.

~~~
nailer
If the VM - the most critical part of the platform - is proprietary, then the
platform isn't largely Open Source.

------
statictype
You can write XULRunner apps in python by adding this extension:
<http://pyxpcomext.mozdev.org/>

------
surki
Conkeror - <http://conkeror.org/>

