This article begs the question, is XUL worth it? I used to be a huge XUL fan years ago. It was a way to create great cross-platform interfaces and, heck, when you look at Firefox you can see that it looks more native than most toolkits. But, my hopes for an independent xulrunner have simply been dashed.
So, the question is, would it be easier to create native interfaces around WebKit and code on that than the combination of coding on Gecko and having "free" cross-platform interfaces. I'd say it probably is still worth it, but we'll see as open source programmers will generally flock to whatever is nice to program in - and with Google's interest, I wouldn't be surprised if an independent WebKit based browser project popped up from some enterprising individual.
Personally, both seem to fit web standards nicely (not perfect, but as someone who has been around a while, I'm happy by comparison to what used to be) and so the competition seems like a good thing - especially since open source can offer a cooperative competition insofar as any WebKit programmer can look at the Gecko code and vice-versa.
To an extent, I think a good bit of this is the "Java is crap and ugly", "Ruby is slow and unscalable" argument where people just like one and so they disparage the other.
XUL is worth it but not for XUL apps. The advantage of Firefox is in the huge body of add-ons. The vast majority of Firefox's add-ons are written in Javascript and XUL. They modify the UI. They add to the UI. They do an amazing level of customization and it's completely cross-platform!
Chrome will never have the comprehensive add-on system that Firefox has specifically because it doesn't have something like XUL; instead it has those different native interfaces for each platform.
The problem with technologies like XUL that come out of browser vendors is their intention is to create a platform that brings people to that particular browser, on the assumption that other browsers will be years behind them in implementing the same technology.
If Mozilla really wanted XUL to be widely adopted, perhaps they should have made it work on every browser, either through a plugin or actually implemented in JavaScript on top of the DOM (the former would be my preference, though as one of the creators of the Cappuccino framework perhaps I'm biased...)
If it's cross-platform interfaces to WebKit that you're after, both Gtk+ and Qt offer widgets that integrate WebKit into their applications. However, I have little experience with either method of using WebKit, so I can't speak to how easily it would be to plug in a Javascript engine, or some other such manner of working directly with the WebKit DOM.
I like webkit a lot, but with my amazing marble mouse I am unable to middle-click scroll. That's pretty much a deal breaker as far as I'm concerned.
Same thing with Opera for the Mac, I just rely too much on the middle click (living without a scroll) that it makes sense that I continue to use Firefox.
So, the question is, would it be easier to create native interfaces around WebKit and code on that than the combination of coding on Gecko and having "free" cross-platform interfaces. I'd say it probably is still worth it, but we'll see as open source programmers will generally flock to whatever is nice to program in - and with Google's interest, I wouldn't be surprised if an independent WebKit based browser project popped up from some enterprising individual.
Personally, both seem to fit web standards nicely (not perfect, but as someone who has been around a while, I'm happy by comparison to what used to be) and so the competition seems like a good thing - especially since open source can offer a cooperative competition insofar as any WebKit programmer can look at the Gecko code and vice-versa.
To an extent, I think a good bit of this is the "Java is crap and ugly", "Ruby is slow and unscalable" argument where people just like one and so they disparage the other.