18 ms·

XUL Layout is gone

486 points by tech234a 4y ago

slater 4y ago
i wonder if that one guy on the mozilla news server who haaaaaaated XUL ("JTK"? something like that) is happy now :D
EGreg 4y ago
So the browser renders all its chrome in web css now?
- slater 4y ago
  "This means that (modulo a few exceptions documented below) all the Firefox UI is using regular web technology to render (mostly CSS flexbox)."
- spankalee 4y ago
  I believe the Firefox UI is mostly standard web components and CSS these days.
- eyelidlessness 4y ago
  It always has been. The fact that it mostly wasn’t noticed for decades should give pause to some of the criticism of web tech as a way to present UI in native apps.
  - kitsunesoba 4y ago
    It's definitely not gone unnoticed. It's the entire reason why Gecko-based native browsers like Camino[0], K-Meleon[1], and the since-turned-WebKit Epiphany[2] existed alongside Firefox. The only reason those ceased to exist is because Mozilla elected to kill Gecko embedding (which in retrospect, also set the stage for Blink and WebKit's dominance with how important embedding would become). [0]: https://en.wikipedia.org/wiki/Camino_(web_browser) https://en.wikipedia.org/wiki/Camino_(web_browser) [1]: https://en.wikipedia.org/wiki/K-Meleon https://en.wikipedia.org/wiki/K-Meleon [2]: https://en.wikipedia.org/wiki/GNOME_Web https://en.wikipedia.org/wiki/GNOME_Web
    - eyelidlessness 4y ago
      Yeah I chose “mostly unnoticed” very purposefully. I used Camino (even when it was Chimera!) because I wanted the native UI it offered. At the time, the vast majority of Mac software was either Cocoa, or ported to Carbon from classic Mac OS, or some Java monstrosity. The tech crowd either didn’t know or didn’t care that Mozilla/Firefox used XUL/web tech to implement its UI, and my preference for the native interface was outlandish to most of my tech peers at the time.
  - happyweasel 4y ago
    500 megs for the browser subprocess is also party of the insanity.
userbinator 4y ago
If we render stuff with the same technologies that websites use, it means performance improvements and bugs that affect the web affect the Firefox UI and vice versa. It also means a UI that's noticeably slower than actual native UI. There's plenty of reasons why I use Firefox instead of other browsers, but the increased UI latency is definitely noticeable and one of the reasons why others might not want to switch to FF.
- vlovich123 4y ago
  Why is XUL inherently faster than web tech?
  - koito17 4y ago
    I'm not very knowledgeable about Firefox internals, but I recall hearing something like XUL having a C++ backend, and being able to use essentially native code to drive UI, extensions (via XPCOM), etc. I figure this is probably faster than rendering a web UI until the SpiderMonkey JIT is sufficiently warm.
    - themerone 4y ago
      XUL is mostly js and XML. You can call native code, but all the XUL ui code I've seen is js.
  - gmueckl 4y ago
    HTML/CSS is horribly, horribly bloated and that cruft cannot be optimized beyond a certain point. All the rules and rule interactions in the standards plus countless hacks and heuristics result in enormous amount of extra code that the CPU has to chew through to compute a layout.
    - shadowgovt 4y ago
      Layouts that don't change can be heavily cached. ... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups. (At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).
GauntletWizard 4y ago
Goodbye to Mozilla's classic joke, https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
- timothyg 4y ago
  XUL is still there. Only XUL layout (homegrown flexbox) is removed.
  - cpeterso 4y ago
    Indeed. There are still 1574 references to XUL's "there.is.only.xul" XML namespace in Firefox code: https://searchfox.org/mozilla-central/search?case=true&q=http%3A%2F%2Fwww.mozilla.org%2Fkeymaster%2Fgatekeeper%2Fthere.is.only.xul https://searchfox.org/mozilla-central/search?case=true&q=htt...
paxcoder 4y ago
[dead]
Dalewyn 4y ago
[flagged]
Dwedit 4y ago
There is no data. There is only XUL!
- ironmagma 4y ago
  And those too weak to seek it.
fnordpiglet 4y ago
I remember starting my career at a small tech startuo making a graphical version of Mosaic and when Xul started at Netscape as the next generation layout engine. Amazing run that’s lasted as long as my career. The pivot to best Microsoft’s free IE by fully open sourcing and establishing a long lived foundation and completely commoditizing the nearly $1B investment they made in browsers was amazing and led to so many amazing technologies. I am humbled to have been a part of that journey and bid Xul a fond farewell. There is no data!!
LispSporks22 4y ago
IIRC, Tom Tom One was an XUL app
taf2 4y ago
My first job after college, we created a healthcare app first using Gtk+ (crazy) with some insane SQL bindings to embedded Firebird database (my youth)... Eventually, after chatting with my brother and some other folks at Mozilla I decided XULRunner was the way forward. So while on a trip to Spain for 4 days I rewrote almost the whole app converting piles of Gtk+ C++ code into JavaScript and wrapping up our Firebird calls into XPCOM interfaces. My main take aways from that experience... 1. Gtk+ is not a great choice at least in 2004 for Windows... but hacking the windows event loop is kinda fun. 2. Embedding C++ into JavaScript was amazing then and still now one of the coolest things about Ruby,Python,JavaScript is being able to write bindings in C/C++ so much fun. 3. XUL was at least in 2005/6 just not as good at rendering as HTML... and it kind of makes sense everyone was hammering away at HTML by browsing the internet. So while XUL had some really great tools, not being HTML meant it just never had the same amount of attention... and as CSS got better the layout abilities of HTML / CSS quickly became #1...
- harryf 4y ago
  From hacking with XUL at around that time too, it could have been a contender if Mozilla had made more effort to document and promote it. The developer experience was like “oh this could be cool to build in XUL” … spend some frustrating days scouring the code of different Firefox extensions to figure out how to do anything … produce an ugly UI that barely serves the purpose … realize XUL was completely unsuited for the purpose.
- JCWasmx86 4y ago
  Nowadays you can even use JS for GTK Applications
  - taf2 4y ago
    So true - I have a special kind of affection for Gtk+ it was my first UI famework. Glade back in 2004 was amazing.
- aembleton 4y ago
  > Firebird database I first found out about this database when Mozilla had to rename the Firebird browser to Firefox.
UberFly 4y ago
I appreciated the author adding "What is (was!) XUL layout?". Goodbye XUL. I used you mightily but didn't even know your name. :(
kurtoid 4y ago
Does Zotero use XUL?
- layer8 4y ago
  Yes [0], and they are going to continue to support it for plugins [1]. [0] https://github.com/zotero/zotero/tree/master/chrome/content/zotero https://github.com/zotero/zotero/tree/master/chrome/content/... [1] https://www.zotero.org/support/dev/zotero_7_for_developers https://www.zotero.org/support/dev/zotero_7_for_developers
  - dstillman 4y ago
    That's a bit different. This is about the XUL box model specifically. What Zotero 7 will continue to support for plugins is full access to the Mozilla platform internals, unlike WebExtensions, but Zotero 7 is based on Firefox 102 ESR and will be updated to 115 ESR later, so platform changes like this do apply. The reason all plugins have to be updated for Zotero 7 is the massive architectural changes in Firefox over the last few years, most notably removal of XUL overlays. This change might require some minor additional updates, but it's probably not a big deal. (Zotero dev)
reitanqild 4y ago
Ok, i loved this, from the linked Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1797272 https://bugzilla.mozilla.org/show_bug.cgi?id=1797272 STR: 1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 22.04. 2. Open a session with 2000 tabs. 3. Pin at least one tab. 4. Drag a tab to different positions in the toolbar at various speeds. The previously smooth tab dragging has become janky and gets progressively worse with increasing number of tabs. It is much more severe on Linux Wayland than XWayland/X11 and can make the entire browser unresponsive for some time. Seems someone is still doing deep work there even if management is busily doing everything else. I so wish someone could get the priorities straight and correct in Mozilla.
- HeavyFeather 4y ago
  [flagged]
  - KerrAvon 4y ago
    You still need to investigate that crash, though. It might be a race condition or some other problem that the user’s bizarro usage has revealed. Doesn’t mean it’s high priority necessarily.
  - numpad0 4y ago
    Surely you can exist as a real estate manager and absolutely do nothing, barely needing a tab, let alone 2048. But there won’t be rampant technological autocomplication that comes of it either.
  - reitanqild 4y ago
    Some people are like me: a well functioning and extremely well liked engineer with a what seems like a significantly smaller short time memory. (This is part of a wider diagnosis.) Having everything I work on - easily, visibly available - in a tree, - sorted and grouped by where I found it from (a natural consequence of using tree style tabs and using ctrl-click to open every link when I am in research mode) helps me a lot. Sure, I can try to be like the cool kids, but why?
xkriva11 4y ago
XULRunner was a great idea. It allowed us to create good-looking desktop applications with a native look&feel with an option to embed HTML and SVG content with only a simple server application. Before it was killed, I created two technologies based on it. Phobos for Pharo and Squeak (see the screenshots): https://github.com/pavel-krivanek/phobos-framework https://github.com/pavel-krivanek/phobos-framework The second one was Seaside inspired XULJet for JavaScript: https://en.wikipedia.org/wiki/XULJet https://en.wikipedia.org/wiki/XULJet At that time, it looked like a good idea to let the hard work of making a platform-independent UI browser on Mozilla and focus on the applications. Unfortunately, it wasn't.
- toyg 4y ago
  The question is really "why wasn't it?"... XUL, conceptually speaking, had a lot of potential, largely squandered by Mozilla-the-corporation. Somewhere between the implementation based on RDF (a literal plague over web tech) and confused commercial strategies, it died a slow death.
  - xkriva11 4y ago
    I call it "The Law of Conservation of Unusability". This states that whenever a technology gets to the point where it becomes usable, where you become comfortable with it and are happy with it, something will always happen that either makes it completely unusable or makes it significantly more difficult to work with. This "something" often has no reasonable justification and the reasons for it look quite artificial.
    - LocalH 4y ago
      Also known as “why we can’t have nice things”
    - deleted 4y ago
      [deleted]
- r12343a_19 4y ago
  It's amazing that for the past 8 years (almost to the day!) imgur has been hosting your screenshots.
876978095789789 4y ago
This was basically Electron before there was Electron. It was hoped that other people would follow the Mozilla Suite's (before Firefox, Mozilla's standard distro was an application suite containing a browser, email reader, chat client, and HTML editor) example and use JavaScript, XUL, and XPCOM to build cross-platform desktop applications. The last of those, XPCOM (Xross Platform COM), was Mozilla's take on Microsoft's Component Object Model, where you would write lower-level components in C or C++ (using the NSPR, Netscape Portable Runtime) that were callable from JavaScript Unfortunately, virtually no one outside of Mozilla adopted the XUL/JS/XPCOM stack. One of the few I remember was ActiveState's Komodo IDE. I still regard it as a huge missed opportunity for Mozilla.
- rwmj 4y ago
  I tried to adopt it, but it was (a) undocumented with no simple examples, (b) ever-changing, and (c) required you to use the Mozilla build system, even IIRC requiring you to basically build your code as part of the browser tree (I don't recall the exact details on this last point, but it was extremely difficult to use). We ditched it quickly and just wrote a Gtk application instead. A great case for why having a simple "hello world" application with simple instructions for building it goes a long way.
  - 876978095789789 4y ago
    >tried to adopt it, but it was (a) undocumented with no simple examples, (b) ever-changing, and (c) required you to use the Mozilla build system, even IIRC requiring you to basically build your code as part of the browser tree (I don't recall the exact details on this last point, but it was extremely difficult to use). you're right, and I almost mentioned some of this. I developed some extensions in 2007-11, and lack of documentation was definitely a big issue.
    - carrja99 4y ago
      I don't get it? I was excited about XUL back in 2007 (call me silly) and there was a whole resource site dedicated to it, complete with documentation and examples. XUL Plannet (https://web.archive.org/web/20070607174323/http://www.xulplanet.com/#content https://web.archive.org/web/20070607174323/http://www.xulpla...) if I recall it correctly. Back then, I wrote a pretty slick client for some RESTful API (I think it was a photo browser for flickr).
butz 4y ago
XUL was one thing that prevented me from using Firefox back in the day, as my PC was slow and whole UI just lagged, as compared to native Windows applications. That's why my main browser then was Opera. Funny enough, Electron now has similar issues with application menus, as they have some lag and works a bit different (compared to native implementation) than one might expect when using keyboard navigation.
- filmor 4y ago
  When was this? I remember that Firefox (or Phoenix, or Firebird) was very fast compared to other browsers (esp. full Mozilla) when it came out.
  - kitsunesoba 4y ago
    Early on Firefox felt fast for sure (on most platforms anyway), but at some point around 4.x or 5 I wanna say it started slowing noticeably, and it would continue on that path until Quantum or thereabouts. On OS X though Firefox always felt a noticeably more laggy and clunky than any other app it might be running alongside — something about the Mac implementation of XULRunner wasn’t optimal and it showed… even if you painstakingly skinned Firefox to match OS X perfectly visually, it still felt kinda slow and clunky. That’s why Camino, which was a Gecko browser with a Cocoa/AppKit UI came into existence, and it always felt a good deal more responsive than Firefox did.
pjmlp 4y ago
Now that XUL is gone, one can hope Electron eventually follows suit.
- creatonez 4y ago
  Firefox isn't switching to a native UI. They are getting rid of a weird web-like DOM-based UI framework and slowly replacing it with actual web stuff. So their answer is "become more electron-like" not "become less electron-like"
  - pjmlp 4y ago
    Whatever Firefox does, no longer matters, it is even worse that The Year of Desktop Linux, and I am typing this from Firefox.
peter_retief 4y ago
I looked at XUL, gosh so it is gone now. In fact I bought a book, something like "Building Rich Internet Applications with XUL" Which I never really read or used.
einpoklum 4y ago
tl;dr: 1. You can do most of it with HTML + CSS these days, so better use that. 2. It's not actually gone, it's a process with a big step taken
Sus_Giraffe 4y ago
[flagged]
meerita 4y ago
I wasn't aware that the UI layout relied on Flex. In my opinion, relying solely on the Flex model can lead to some flaws in UI layouting. I wonder when Firefox plans to switch to using CSS Grid instead of CSS Flex?
- mort96 4y ago
  Are there any flaws in the Firefox UI which is caused by flex at the moment? If not, what's the problem?
  - meerita 4y ago
    Just to clarify, I have not experienced any bugs in Firefox, nor am I stating that there are any present. However, I do believe that when it comes to creating layouts, CSS Grid is a more effective tool than Flex. While Flex is great for inline-oriented designs, CSS Grid's grid-oriented approach makes it significantly more efficient for creating complex layouts.
toyg 4y ago
> XUL is a specific XML namespace (like HTML or SVG) Er, HTML is not an XML namespace, it's a SGML implementation. W3C tried to retrofit it on XML with XHTML but that was then abandoned. Modern HTML is not XML-compliant in various ways. I expect this kind of casual lie from the average developer, not from the guy working on XUL at Mozilla. /Pedantry
- notpushkin 4y ago
  XHTML still works by the way, all HTML5 goodness included. I tend to write sites in XHTML myself as default HTML parsing feels broken in many subtle ways.
  - mort96 4y ago
    Heh, I wouldn't even know which URLs to put in the doctype for XHTML. I certainly won't ever memorize it. As long as HTML is `<!DOCTYPE html>` and XHTML is `<!DOCTYPE some ridiculously long string with a bunch of URLs and crap>` I don't think I'll be using XHTML. It's also pretty risky to let any slight syntax error or semantic error cause the whole page to refuse to load. That would turn me off from targeting XHTML for any kind of dynamic page generation, not because I want to generate incorrect HTML or XHTML or whatever, but because bugs happen.
    - notpushkin 4y ago
      XHTML works fine even without a doctype actually (or with a <!DOCTYPE html>). The stricter syntax is a double-edged sword though, I agree.
      - mort96 4y ago
        Won't the browser just interpret that as an HTML document then?
        notpushkin 4y ago
        Nope. The thing that browser looks for is the Content-Type header – if it's set to application/xhtml+xml, it will parse the document as XHTML. For static sites, just setting extension to .xhtml is usually enough.
osener 4y ago
I have fond memories of Conkeror, a standalone browser built with XUL and the Firefox rendering engine. For a relatively brief moment in time, it was ahead of the competition. The absence of Firefox's baggage allowed it to launch quickly and be highly programmable. However, over time, the importance of browser add-on stores grew, and Conkeror's strength turned into a weakness. Vimperator and similar extensions, by nature of being another extension, had compatibility with ad blockers, password managers, and other essential extensions. Meanwhile, Conkeror stagnated. I still miss it, as it was essentially Emacs-for-web, programmable in JavaScript.
- mtrower 4y ago
  I was very sad when Conkeror when to rest. You might be interested in Nyxt, if cl doesn’t turn you off.
- tinus_hn 4y ago
  Was this created before or after Konqueror, the KDE web browser (which coincidentally is the source for the WebKit/Chromium browsers)?
bxjx 4y ago
Fond memories! My first job out of uni was building interfaces for embedded devices using XUL/javsacript/xpcom/c++. The technologies were fun to develop in at the time and it felt special to be somewhat of a part of such a big open project.
vrglvrglvrgl 4y ago
[dead]
EntrePrescott 4y ago
What's really sad imho isn't that XUL is gone (when I considered using it, I quickly gave it up for mostly the same reasons that several others already wrote about ITT)… … no, what's really sad is that there is still no satisfying solution to the problem that XUL was trying to solve, i.e.: the need for a native cross-platform GUI lib; and apart from the special situation of the likes of Mozilla (where a Web browser engine is the central major part of the product and its UI anyways so it makes sense that they use that engine for what little and relatively simple and not performance-sensitive GUI is added to or around the browser view as well)… … apart from very few such cases, Web isn't the answer either. In particular, Electron apps suffer from the unnecessarily enormous added deadweight of the de-facto-integrated browser and while its performance is good enough for simple use cases, it quickly becomes limiting when the UI gets more complex or when you need to integrate stuff that is performance-sensitive or requires a different rendering. There are a couple cross-platform UI libs out there, but compared to other domains (where it's often easier to find a satisfying lib), I find that they all have some major problems, in particular: * Qt, which did look promising in its Nokia days, went down a sore downhill shitslope since Microsoft mole Stephen Elop threw it out to Digia, where (especially since splitted out as QTCOM) the licensing focus of Qt has shifted from "make it more open and permissive so as to gain wide dev community/traction" (the strategy under Nokia) to "try to force devs into commercial licensing schemes and monetize to the max you can milk out of it while it lasts"… and as a consequence, more and more previously Qt-oriented devs looking elsewhere. * neither GTK nor Flutter are satisfying answers either. I think there is really a big window of opportunity and gap to be filled by a new modern cross-platform UI toolkit with wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded; though a Vulkan-based renderer can be made to run pretty much anywhere), a permissive open source license, a C interface/wrap to allow a wide programming language binding support, and an easily extensible and themable set of basic widgets.
- le-mark 4y ago
  It’s a tough problem and the fact that in 2023 there is no defacto solutions is a good indicator. Certainly there are contenders and they’ll be commented here. In my experience selling a cross platform shareware app around 2010 (when that was still a thing) the best practice if you wanted a consistent user experience was to use the platform native framework and make the application code as modular and independent as possible. My sense is that is mostly the same today.
c-smile 4y ago
> With XUL, something like width: 100px wouldn’t quite do what it says. Same statement can be applied to display: flexbox. It also breaks CSS box model in that sense. For example flex properties with obvious names like flex-basis, align-items(!) can change box dimensions completely.
bradwood 4y ago
> This means that (modulo a few exceptions documented below) all the Firefox UI is using regular web technology to render (mostly CSS flexbox). Is it just me or is using the word "modulo" here (when "apart from","other than for" or "barring" would do) just completely pretentious?
- thiht 4y ago
  Not necessarily. In France for example it’s used as an expression even by people who don’t know the math meaning. I know I use it because I sometimes read it in general news articles. It’s not common but definitely used. The author appears to be Spanish, maybe it’s the same.
  - bradwood 4y ago
    Fair enough. A cursory glance at a dictionary corroborates your point - there is clearly a colloquial usage too. I guess I'd never heard its use except in the much more narrow mathematical sense, until now.
latortuga 4y ago
Raising my hand as another dev that hacked on a desktop app using XULRunner back in 2008-2010. Docs were kinda bad but we made it work. The startup was acquired so I guess it worked well enough!
sli 4y ago
I'm confused. This seems to just refer to XUL layout and not XUL as a whole, but this entire thread is discussing it like XUL as a whole is completely gone. Am I missing something?
sroussey 4y ago
XUL is dead! Long live WebComponents!
- sroussey 4y ago
  BTW, we had altered Firebug to list XUL stuff as well (activated when using firebug on firebug). It was everywhere. The <input type=“text” was actually a couple of things with padding, etc. inside.
modelbehaviour 4y ago
[dead]
behindmylens1 4y ago
[dead]
feedingthefeed 4y ago
[dead]

XUL Layout is gone

486 points by tech234a 4y ago

slater 4y ago

i wonder if that one guy on the mozilla news server who haaaaaaated XUL ("JTK"? something like that) is happy now :D

EGreg 4y ago

So the browser renders all its chrome in web css now?

slater 4y ago
"This means that (modulo a few exceptions documented below) all the Firefox UI is using regular web technology to render (mostly CSS flexbox)."
spankalee 4y ago
I believe the Firefox UI is mostly standard web components and CSS these days.
eyelidlessness 4y ago
It always has been. The fact that it mostly wasn’t noticed for decades should give pause to some of the criticism of web tech as a way to present UI in native apps.
- kitsunesoba 4y ago
  It's definitely not gone unnoticed. It's the entire reason why Gecko-based native browsers like Camino[0], K-Meleon[1], and the since-turned-WebKit Epiphany[2] existed alongside Firefox. The only reason those ceased to exist is because Mozilla elected to kill Gecko embedding (which in retrospect, also set the stage for Blink and WebKit's dominance with how important embedding would become). [0]: https://en.wikipedia.org/wiki/Camino_(web_browser) https://en.wikipedia.org/wiki/Camino_(web_browser) [1]: https://en.wikipedia.org/wiki/K-Meleon https://en.wikipedia.org/wiki/K-Meleon [2]: https://en.wikipedia.org/wiki/GNOME_Web https://en.wikipedia.org/wiki/GNOME_Web
  - eyelidlessness 4y ago
    Yeah I chose “mostly unnoticed” very purposefully. I used Camino (even when it was Chimera!) because I wanted the native UI it offered. At the time, the vast majority of Mac software was either Cocoa, or ported to Carbon from classic Mac OS, or some Java monstrosity. The tech crowd either didn’t know or didn’t care that Mozilla/Firefox used XUL/web tech to implement its UI, and my preference for the native interface was outlandish to most of my tech peers at the time.
- happyweasel 4y ago
  500 megs for the browser subprocess is also party of the insanity.

userbinator 4y ago

If we render stuff with the same technologies that websites use, it means performance improvements and bugs that affect the web affect the Firefox UI and vice versa. It also means a UI that's noticeably slower than actual native UI. There's plenty of reasons why I use Firefox instead of other browsers, but the increased UI latency is definitely noticeable and one of the reasons why others might not want to switch to FF.

vlovich123 4y ago
Why is XUL inherently faster than web tech?
- koito17 4y ago
  I'm not very knowledgeable about Firefox internals, but I recall hearing something like XUL having a C++ backend, and being able to use essentially native code to drive UI, extensions (via XPCOM), etc. I figure this is probably faster than rendering a web UI until the SpiderMonkey JIT is sufficiently warm.
  - themerone 4y ago
    XUL is mostly js and XML. You can call native code, but all the XUL ui code I've seen is js.
- gmueckl 4y ago
  HTML/CSS is horribly, horribly bloated and that cruft cannot be optimized beyond a certain point. All the rules and rule interactions in the standards plus countless hacks and heuristics result in enormous amount of extra code that the CPU has to chew through to compute a layout.
  - shadowgovt 4y ago
    Layouts that don't change can be heavily cached. ... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups. (At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).

GauntletWizard 4y ago

Goodbye to Mozilla's classic joke, https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...

timothyg 4y ago
XUL is still there. Only XUL layout (homegrown flexbox) is removed.
- cpeterso 4y ago
  Indeed. There are still 1574 references to XUL's "there.is.only.xul" XML namespace in Firefox code: https://searchfox.org/mozilla-central/search?case=true&q=http%3A%2F%2Fwww.mozilla.org%2Fkeymaster%2Fgatekeeper%2Fthere.is.only.xul https://searchfox.org/mozilla-central/search?case=true&q=htt...

paxcoder 4y ago

[dead]

Dalewyn 4y ago

[flagged]

Dwedit 4y ago

There is no data. There is only XUL!

ironmagma 4y ago
And those too weak to seek it.

fnordpiglet 4y ago

I remember starting my career at a small tech startuo making a graphical version of Mosaic and when Xul started at Netscape as the next generation layout engine. Amazing run that’s lasted as long as my career. The pivot to best Microsoft’s free IE by fully open sourcing and establishing a long lived foundation and completely commoditizing the nearly $1B investment they made in browsers was amazing and led to so many amazing technologies. I am humbled to have been a part of that journey and bid Xul a fond farewell. There is no data!!

LispSporks22 4y ago

IIRC, Tom Tom One was an XUL app

taf2 4y ago

My first job after college, we created a healthcare app first using Gtk+ (crazy) with some insane SQL bindings to embedded Firebird database (my youth)... Eventually, after chatting with my brother and some other folks at Mozilla I decided XULRunner was the way forward. So while on a trip to Spain for 4 days I rewrote almost the whole app converting piles of Gtk+ C++ code into JavaScript and wrapping up our Firebird calls into XPCOM interfaces. My main take aways from that experience... 1. Gtk+ is not a great choice at least in 2004 for Windows... but hacking the windows event loop is kinda fun. 2. Embedding C++ into JavaScript was amazing then and still now one of the coolest things about Ruby,Python,JavaScript is being able to write bindings in C/C++ so much fun. 3. XUL was at least in 2005/6 just not as good at rendering as HTML... and it kind of makes sense everyone was hammering away at HTML by browsing the internet. So while XUL had some really great tools, not being HTML meant it just never had the same amount of attention... and as CSS got better the layout abilities of HTML / CSS quickly became #1...

harryf 4y ago
From hacking with XUL at around that time too, it could have been a contender if Mozilla had made more effort to document and promote it. The developer experience was like “oh this could be cool to build in XUL” … spend some frustrating days scouring the code of different Firefox extensions to figure out how to do anything … produce an ugly UI that barely serves the purpose … realize XUL was completely unsuited for the purpose.
JCWasmx86 4y ago
Nowadays you can even use JS for GTK Applications
- taf2 4y ago
  So true - I have a special kind of affection for Gtk+ it was my first UI famework. Glade back in 2004 was amazing.
aembleton 4y ago
> Firebird database I first found out about this database when Mozilla had to rename the Firebird browser to Firefox.

UberFly 4y ago

I appreciated the author adding "What is (was!) XUL layout?". Goodbye XUL. I used you mightily but didn't even know your name. :(

kurtoid 4y ago

Does Zotero use XUL?

layer8 4y ago
Yes [0], and they are going to continue to support it for plugins [1]. [0] https://github.com/zotero/zotero/tree/master/chrome/content/zotero https://github.com/zotero/zotero/tree/master/chrome/content/... [1] https://www.zotero.org/support/dev/zotero_7_for_developers https://www.zotero.org/support/dev/zotero_7_for_developers
- dstillman 4y ago
  That's a bit different. This is about the XUL box model specifically. What Zotero 7 will continue to support for plugins is full access to the Mozilla platform internals, unlike WebExtensions, but Zotero 7 is based on Firefox 102 ESR and will be updated to 115 ESR later, so platform changes like this do apply. The reason all plugins have to be updated for Zotero 7 is the massive architectural changes in Firefox over the last few years, most notably removal of XUL overlays. This change might require some minor additional updates, but it's probably not a big deal. (Zotero dev)

reitanqild 4y ago

Ok, i loved this, from the linked Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1797272 https://bugzilla.mozilla.org/show_bug.cgi?id=1797272 STR: 1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 22.04. 2. Open a session with 2000 tabs. 3. Pin at least one tab. 4. Drag a tab to different positions in the toolbar at various speeds. The previously smooth tab dragging has become janky and gets progressively worse with increasing number of tabs. It is much more severe on Linux Wayland than XWayland/X11 and can make the entire browser unresponsive for some time. Seems someone is still doing deep work there even if management is busily doing everything else. I so wish someone could get the priorities straight and correct in Mozilla.

HeavyFeather 4y ago
[flagged]
- KerrAvon 4y ago
  You still need to investigate that crash, though. It might be a race condition or some other problem that the user’s bizarro usage has revealed. Doesn’t mean it’s high priority necessarily.
- numpad0 4y ago
  Surely you can exist as a real estate manager and absolutely do nothing, barely needing a tab, let alone 2048. But there won’t be rampant technological autocomplication that comes of it either.
- reitanqild 4y ago
  Some people are like me: a well functioning and extremely well liked engineer with a what seems like a significantly smaller short time memory. (This is part of a wider diagnosis.) Having everything I work on - easily, visibly available - in a tree, - sorted and grouped by where I found it from (a natural consequence of using tree style tabs and using ctrl-click to open every link when I am in research mode) helps me a lot. Sure, I can try to be like the cool kids, but why?

xkriva11 4y ago

XULRunner was a great idea. It allowed us to create good-looking desktop applications with a native look&feel with an option to embed HTML and SVG content with only a simple server application. Before it was killed, I created two technologies based on it. Phobos for Pharo and Squeak (see the screenshots): https://github.com/pavel-krivanek/phobos-framework https://github.com/pavel-krivanek/phobos-framework The second one was Seaside inspired XULJet for JavaScript: https://en.wikipedia.org/wiki/XULJet https://en.wikipedia.org/wiki/XULJet At that time, it looked like a good idea to let the hard work of making a platform-independent UI browser on Mozilla and focus on the applications. Unfortunately, it wasn't.

toyg 4y ago
The question is really "why wasn't it?"... XUL, conceptually speaking, had a lot of potential, largely squandered by Mozilla-the-corporation. Somewhere between the implementation based on RDF (a literal plague over web tech) and confused commercial strategies, it died a slow death.
- xkriva11 4y ago
  I call it "The Law of Conservation of Unusability". This states that whenever a technology gets to the point where it becomes usable, where you become comfortable with it and are happy with it, something will always happen that either makes it completely unusable or makes it significantly more difficult to work with. This "something" often has no reasonable justification and the reasons for it look quite artificial.
  - LocalH 4y ago
    Also known as “why we can’t have nice things”
  - deleted 4y ago
    [deleted]
r12343a_19 4y ago
It's amazing that for the past 8 years (almost to the day!) imgur has been hosting your screenshots.

876978095789789 4y ago

This was basically Electron before there was Electron. It was hoped that other people would follow the Mozilla Suite's (before Firefox, Mozilla's standard distro was an application suite containing a browser, email reader, chat client, and HTML editor) example and use JavaScript, XUL, and XPCOM to build cross-platform desktop applications. The last of those, XPCOM (Xross Platform COM), was Mozilla's take on Microsoft's Component Object Model, where you would write lower-level components in C or C++ (using the NSPR, Netscape Portable Runtime) that were callable from JavaScript Unfortunately, virtually no one outside of Mozilla adopted the XUL/JS/XPCOM stack. One of the few I remember was ActiveState's Komodo IDE. I still regard it as a huge missed opportunity for Mozilla.

rwmj 4y ago
I tried to adopt it, but it was (a) undocumented with no simple examples, (b) ever-changing, and (c) required you to use the Mozilla build system, even IIRC requiring you to basically build your code as part of the browser tree (I don't recall the exact details on this last point, but it was extremely difficult to use). We ditched it quickly and just wrote a Gtk application instead. A great case for why having a simple "hello world" application with simple instructions for building it goes a long way.
- 876978095789789 4y ago
  >tried to adopt it, but it was (a) undocumented with no simple examples, (b) ever-changing, and (c) required you to use the Mozilla build system, even IIRC requiring you to basically build your code as part of the browser tree (I don't recall the exact details on this last point, but it was extremely difficult to use). you're right, and I almost mentioned some of this. I developed some extensions in 2007-11, and lack of documentation was definitely a big issue.
  - carrja99 4y ago
    I don't get it? I was excited about XUL back in 2007 (call me silly) and there was a whole resource site dedicated to it, complete with documentation and examples. XUL Plannet (https://web.archive.org/web/20070607174323/http://www.xulplanet.com/#content https://web.archive.org/web/20070607174323/http://www.xulpla...) if I recall it correctly. Back then, I wrote a pretty slick client for some RESTful API (I think it was a photo browser for flickr).

butz 4y ago

XUL was one thing that prevented me from using Firefox back in the day, as my PC was slow and whole UI just lagged, as compared to native Windows applications. That's why my main browser then was Opera. Funny enough, Electron now has similar issues with application menus, as they have some lag and works a bit different (compared to native implementation) than one might expect when using keyboard navigation.

filmor 4y ago
When was this? I remember that Firefox (or Phoenix, or Firebird) was very fast compared to other browsers (esp. full Mozilla) when it came out.
- kitsunesoba 4y ago
  Early on Firefox felt fast for sure (on most platforms anyway), but at some point around 4.x or 5 I wanna say it started slowing noticeably, and it would continue on that path until Quantum or thereabouts. On OS X though Firefox always felt a noticeably more laggy and clunky than any other app it might be running alongside — something about the Mac implementation of XULRunner wasn’t optimal and it showed… even if you painstakingly skinned Firefox to match OS X perfectly visually, it still felt kinda slow and clunky. That’s why Camino, which was a Gecko browser with a Cocoa/AppKit UI came into existence, and it always felt a good deal more responsive than Firefox did.

pjmlp 4y ago

Now that XUL is gone, one can hope Electron eventually follows suit.

creatonez 4y ago
Firefox isn't switching to a native UI. They are getting rid of a weird web-like DOM-based UI framework and slowly replacing it with actual web stuff. So their answer is "become more electron-like" not "become less electron-like"
- pjmlp 4y ago
  Whatever Firefox does, no longer matters, it is even worse that The Year of Desktop Linux, and I am typing this from Firefox.

peter_retief 4y ago

I looked at XUL, gosh so it is gone now. In fact I bought a book, something like "Building Rich Internet Applications with XUL" Which I never really read or used.

einpoklum 4y ago

tl;dr: 1. You can do most of it with HTML + CSS these days, so better use that. 2. It's not actually gone, it's a process with a big step taken

Sus_Giraffe 4y ago

[flagged]

meerita 4y ago

I wasn't aware that the UI layout relied on Flex. In my opinion, relying solely on the Flex model can lead to some flaws in UI layouting. I wonder when Firefox plans to switch to using CSS Grid instead of CSS Flex?

mort96 4y ago
Are there any flaws in the Firefox UI which is caused by flex at the moment? If not, what's the problem?
- meerita 4y ago
  Just to clarify, I have not experienced any bugs in Firefox, nor am I stating that there are any present. However, I do believe that when it comes to creating layouts, CSS Grid is a more effective tool than Flex. While Flex is great for inline-oriented designs, CSS Grid's grid-oriented approach makes it significantly more efficient for creating complex layouts.

toyg 4y ago

> XUL is a specific XML namespace (like HTML or SVG) Er, HTML is not an XML namespace, it's a SGML implementation. W3C tried to retrofit it on XML with XHTML but that was then abandoned. Modern HTML is not XML-compliant in various ways. I expect this kind of casual lie from the average developer, not from the guy working on XUL at Mozilla. /Pedantry

notpushkin 4y ago
XHTML still works by the way, all HTML5 goodness included. I tend to write sites in XHTML myself as default HTML parsing feels broken in many subtle ways.
- mort96 4y ago
  Heh, I wouldn't even know which URLs to put in the doctype for XHTML. I certainly won't ever memorize it. As long as HTML is `<!DOCTYPE html>` and XHTML is `<!DOCTYPE some ridiculously long string with a bunch of URLs and crap>` I don't think I'll be using XHTML. It's also pretty risky to let any slight syntax error or semantic error cause the whole page to refuse to load. That would turn me off from targeting XHTML for any kind of dynamic page generation, not because I want to generate incorrect HTML or XHTML or whatever, but because bugs happen.
  - notpushkin 4y ago
    XHTML works fine even without a doctype actually (or with a <!DOCTYPE html>). The stricter syntax is a double-edged sword though, I agree.
    - mort96 4y ago
      Won't the browser just interpret that as an HTML document then?
      - notpushkin 4y ago
        Nope. The thing that browser looks for is the Content-Type header – if it's set to application/xhtml+xml, it will parse the document as XHTML. For static sites, just setting extension to .xhtml is usually enough.

osener 4y ago

I have fond memories of Conkeror, a standalone browser built with XUL and the Firefox rendering engine. For a relatively brief moment in time, it was ahead of the competition. The absence of Firefox's baggage allowed it to launch quickly and be highly programmable. However, over time, the importance of browser add-on stores grew, and Conkeror's strength turned into a weakness. Vimperator and similar extensions, by nature of being another extension, had compatibility with ad blockers, password managers, and other essential extensions. Meanwhile, Conkeror stagnated. I still miss it, as it was essentially Emacs-for-web, programmable in JavaScript.

mtrower 4y ago
I was very sad when Conkeror when to rest. You might be interested in Nyxt, if cl doesn’t turn you off.
tinus_hn 4y ago
Was this created before or after Konqueror, the KDE web browser (which coincidentally is the source for the WebKit/Chromium browsers)?

bxjx 4y ago

Fond memories! My first job out of uni was building interfaces for embedded devices using XUL/javsacript/xpcom/c++. The technologies were fun to develop in at the time and it felt special to be somewhat of a part of such a big open project.

vrglvrglvrgl 4y ago

[dead]

EntrePrescott 4y ago

What's really sad imho isn't that XUL is gone (when I considered using it, I quickly gave it up for mostly the same reasons that several others already wrote about ITT)… … no, what's really sad is that there is still no satisfying solution to the problem that XUL was trying to solve, i.e.: the need for a native cross-platform GUI lib; and apart from the special situation of the likes of Mozilla (where a Web browser engine is the central major part of the product and its UI anyways so it makes sense that they use that engine for what little and relatively simple and not performance-sensitive GUI is added to or around the browser view as well)… … apart from very few such cases, Web isn't the answer either. In particular, Electron apps suffer from the unnecessarily enormous added deadweight of the de-facto-integrated browser and while its performance is good enough for simple use cases, it quickly becomes limiting when the UI gets more complex or when you need to integrate stuff that is performance-sensitive or requires a different rendering. There are a couple cross-platform UI libs out there, but compared to other domains (where it's often easier to find a satisfying lib), I find that they all have some major problems, in particular: * Qt, which did look promising in its Nokia days, went down a sore downhill shitslope since Microsoft mole Stephen Elop threw it out to Digia, where (especially since splitted out as QTCOM) the licensing focus of Qt has shifted from "make it more open and permissive so as to gain wide dev community/traction" (the strategy under Nokia) to "try to force devs into commercial licensing schemes and monetize to the max you can milk out of it while it lasts"… and as a consequence, more and more previously Qt-oriented devs looking elsewhere. * neither GTK nor Flutter are satisfying answers either. I think there is really a big window of opportunity and gap to be filled by a new modern cross-platform UI toolkit with wide portability (at least Windoze, Linux, MacOS, iOS, Android, embedded; though a Vulkan-based renderer can be made to run pretty much anywhere), a permissive open source license, a C interface/wrap to allow a wide programming language binding support, and an easily extensible and themable set of basic widgets.

le-mark 4y ago
It’s a tough problem and the fact that in 2023 there is no defacto solutions is a good indicator. Certainly there are contenders and they’ll be commented here. In my experience selling a cross platform shareware app around 2010 (when that was still a thing) the best practice if you wanted a consistent user experience was to use the platform native framework and make the application code as modular and independent as possible. My sense is that is mostly the same today.

c-smile 4y ago

> With XUL, something like width: 100px wouldn’t quite do what it says. Same statement can be applied to display: flexbox. It also breaks CSS box model in that sense. For example flex properties with obvious names like flex-basis, align-items(!) can change box dimensions completely.

bradwood 4y ago

> This means that (modulo a few exceptions documented below) all the Firefox UI is using regular web technology to render (mostly CSS flexbox). Is it just me or is using the word "modulo" here (when "apart from","other than for" or "barring" would do) just completely pretentious?

thiht 4y ago
Not necessarily. In France for example it’s used as an expression even by people who don’t know the math meaning. I know I use it because I sometimes read it in general news articles. It’s not common but definitely used. The author appears to be Spanish, maybe it’s the same.
- bradwood 4y ago
  Fair enough. A cursory glance at a dictionary corroborates your point - there is clearly a colloquial usage too. I guess I'd never heard its use except in the much more narrow mathematical sense, until now.

latortuga 4y ago

Raising my hand as another dev that hacked on a desktop app using XULRunner back in 2008-2010. Docs were kinda bad but we made it work. The startup was acquired so I guess it worked well enough!

sli 4y ago

I'm confused. This seems to just refer to XUL layout and not XUL as a whole, but this entire thread is discussing it like XUL as a whole is completely gone. Am I missing something?

sroussey 4y ago

XUL is dead! Long live WebComponents!

sroussey 4y ago
BTW, we had altered Firebug to list XUL stuff as well (activated when using firebug on firebug). It was everywhere. The <input type=“text” was actually a couple of things with padding, etc. inside.

modelbehaviour 4y ago

[dead]

behindmylens1 4y ago

[dead]

feedingthefeed 4y ago

[dead]