Firefox: An Acceptable Cross Platform GUI Toolkit(ynniv.com)
ynniv.com
Firefox: An Acceptable Cross Platform GUI Toolkit
http://ynniv.com/blog/2009/01/firefox-acceptable-cross-platform-gui.html
31 comments
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.
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.
>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.
The reason is that when it came out it was competing with WinAmp 1.x which was the antithesis of sluggish.
This is my complaint about Komodo Edit. It has a lot of really nice features, but it's just slow compared to other editors (and even compared to Eclipse).
Y'know, I really feel bad for the folks at ActiveState. They put so much into Komodo. Really drank the Mozilla koolaid, I guess. And it's a great product, ... except for the speed. And they're a smart bunch. If there were a way to speed it up, you'd think they'd have found it.
I hate to say this, but you know what I'd really like to see happen? For them to cut their losses. Just take everything in Komodo that's not tied to the XUL (or whatever Mozilla pieces they're using), and redo their GUI in ... well, there's more discussion on that in this HN thread: http://news.ycombinator.com/item?id=423119
I hate to say this, but you know what I'd really like to see happen? For them to cut their losses. Just take everything in Komodo that's not tied to the XUL (or whatever Mozilla pieces they're using), and redo their GUI in ... well, there's more discussion on that in this HN thread: http://news.ycombinator.com/item?id=423119
Are you using Linux, where fsync() syncs the entire filesystem rather than a single file?
SQLite (interoduced in FF3 for settings) calls fsync lots, hence tends to suck a bit on Linux. That's Linux's fault, not Firefox's.
Was FF2 preferences slow?
SQLite (interoduced in FF3 for settings) calls fsync lots, hence tends to suck a bit on Linux. That's Linux's fault, not Firefox's.
Was FF2 preferences slow?
Another reason why it hasn't caught on, is its bloated/complex build infrastructure.
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.
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.
Which, of course, begs a link to jerf's critique of this idea: http://www.jerf.org/resources/xblinjs/whyNotMozilla/index.ht... . 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.
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.
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... around 2:40, where the script driving the little Nazi is actually the scripting language QT ships with based on Ecmascript.
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... around 2:40, where the script driving the little Nazi is actually the scripting language QT ships with based on Ecmascript.
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
[1] http://hacketyhack.net [2] http://shoooes.net
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.
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.
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.
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.
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?
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?
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.
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.)
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.)
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)
(Some people care about free software, others don't. Just thought I'd mention an alternative)
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+...
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.
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.
If the VM - the most critical part of the platform - is proprietary, then the platform isn't largely Open Source.
http://titaniumapp.com/ if you want an open source AIR equivalent. It's a work in progress but seems promising.
Er, that's JavaScript and only runs in the browser. The toolkits we're discussing are concerned with desktop apps.
Well the parent mentioned extjs, which is javascript and only runs in the browser.
And you can run both (last I checked) in AIR as AIR contains WebKit.
And you can run both (last I checked) in AIR as AIR contains WebKit.
Great if you want an application to look like a web app, but it's not an ideal solution by any stretch.
You can write XULRunner apps in python by adding this extension: http://pyxpcomext.mozdev.org/
Conkeror - http://conkeror.org/
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.