XUL was ahead of its time when it was introduced by Netscape/Mozilla many years ago. It was a capable XML based language used to describe rich graphical user interfaces. Together with XULRunner this was supposed to be a generic framework for creating graphical applications.
This was long before HTML became what it is today. Back then people still thought Java would take off on the desktop.
I believe that most Mozilla products such as the Mozilla suite, Thunderbird and Firefox used this for a very long time.<p><a href="https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" rel="nofollow">https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...</a>
I'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS.<p>It's luckily on Bugzilla, so I can keep monitoring progress daily.<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=34572" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=34572</a>
Here’s my XUL development story:<p>I built and managed (2009-2011) the XUL-based Elasticfox extension for Firefox that allowed users of EC2 to manage their compute resources on AWS. The extension pre-dated the AWS Console and introduced features such as resource tagging and search before they were part of the SDK.<p>The extension wouldn’t have been possible without XUL. In fact, it isn’t possible today. MDN documentation was really great even in those days, as was the community which answered a number of my questions. I was doing something really new, especially with calling into EC2 APIs, background refreshes, using Prefs.js to save tag information, etc., and the community was really responsive and supportive of my work. Quirks aside, my experience with XUL was great. Users truly appreciated the extension over the Java-based CLI, and a number of ideas (mine or those from the community) eventually made their way into the AWS Console.<p>I spent my last year at AWS working on the S3 Console using web technologies. I found XUL development to be easier than hacking CSS that year (circa 2010-11).<p>Edit: Added a note up top that this is my XUL story.
Isn't this the kind of thing we've been looking to move away from?
I personally think that this modern trend of implementing, or even worse -porting-, important functionality in Javascript is very worrying. There was another recent controversial discussion of Electron on HN where I and many others shared our reservations about badly Electron apps perform overall. They're disproportionately resource intensive, shred battery life, hog resources etc.
I don't think that deprecating XUL is a bad thing, but is moving to another JS based solution <i>really</i> a good idea?
I've been a supporter of Firefox for a long time and intend to continue to do so. I tend to favor lightweight programs and while I want to continue to give FF my support, I'm concerned with how bloated and slow it's becoming.
Just peeking through the tracker history <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1397874" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1397874</a> and you can see the effort it took to land this magnitude of a change -- pretty astounding. Big hat tip to Brian and the FF crew!
I built a userChrome.js replacement [+] back when FF 57 came around, that uses an XBL loophole to permit users to add custom javascript to their profiles that would run in the browser context. I wanted to be able to use pre-OS X Lion fullscreen mode, and couldn't find any other way to do it.<p>I'm a little bummed that this loophole is going away in FF 72 (I still can't get pre-Lion fullscreen!). On the other hand, it has always been super clear that this is a loophole that will eventually go away, and I did get 2 years of use out of it, so I'm not complaining too loudly. Congrats to the team for removing XBL!<p>[+] <a href="https://github.com/nuchi/firefox-quantum-userchromejs" rel="nofollow">https://github.com/nuchi/firefox-quantum-userchromejs</a>
> There was also a case where a user with over 1500 tabs open (scientifically considered a “tab hoarder”) noticed extreme slowness when opening the “all tabs” dropdown. It turned out that he had tripped on an O(N²) edge case, and the issue was fixed.<p>Good god.I've seen some ridiculous tab collections but that is next level.
can it cause perfomance issue ?<p>I know for example the devtool is written in react and it's a lot slower than chrome devtools (I don't know how chrome devtool is written) and the javascript debugger is sometime not even usable because it's so slow.
I wrote an open-source cross platform app entirely in XUL + Javascript once and it was an awful experience - incredibly hard to debug and get all the bindings working right. Congrats to the Mozilla team on what has to be a very satisfying improvement!
I don't know if the move to web components somehow resulted in superior font rendering for Firefox on Mac, but I just checked version 71.0b11 and it looks great – at least as good as Safari.<p>I just couldn't stand the blurry text, so now I'll give it a go and switch back to Firefox. Although, the colors look far more saturated than they should be, like the orange Hacker News navigation bar.
I read the blog post and wasn't able to figure out if this would break userChrome.css.<p>I'm not that weird about change and normally accept it and end up not caring. But I have tried to get used to tabs on top and it just isn't happening. If I can no longer have that I guess I will need to get used to Safari. Or I will just keep using Firefox and not update and accept the security implications.
Does this mean the missing extension icons I got for a few days now are because of this? (I use nightly) or is this an uncorrelated bug and I now think that the rewrite is at fault because I combine unrelated information?
Was there a reason for XUL in the first place? Why wasn't Firefox built using some GUI library? I've read what the posted page said, and the comments in here, and the first results from Google don't give any reason why XUL was necessary.<p>To me it seems many hundreds, if not thousand, man years spent on something totally unnecessary.
And the FireFox UI still sucks. It's ugly and clunky. The look and feel is just off, and it isn't responsive.<p>One of the reasons I prefer Safari on macOS is that it actually has a native Cocoa UI.
Bah, I was wondering why it suddenly feels less snappy. Generally I am against Electron and other web based UI layers. However since browser must have built in web GUI framework by definition it does make mush sense from the architectural and business standpoint to use the same thing for browser own GUI as well.