XMLUI

XUL was created by Netscape employees for Netscape's XPToolkit project¹. I didn't think that saying that "Mozilla² adopted XUL" would be considered controversial or somehow denigrating, so apologies if if came off that way.

AOL acquired Netscape in 1999, then became the first company to ship XUL as part of Netscape 6 in 2000. https://en.wikipedia.org/wiki/Netscape_6#:~:text=With%20publ... AOL abandoned XUL to the Mozilla open source community not long after, when they disbanded the Netscape team in 2003.²

> Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious.

WML, XFDL, and Glade XML all shipped in 1998, two years before Netscape 6. Adobe's XFA also shipped before Netscape 6.

¹ https://www-archive.mozilla.org/xpfe/whoswho ² at the time meaning, "the software suite formerly known as Netscape Communicator" ³ https://www.mentalfloss.com/article/502789/day-2003-netscape...

I worked on the cross platform TomTom Home content management app in 2007-2008, which used XULRunner and XP/COM extensively.

But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.

Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.

https://en.wikipedia.org/wiki/TomTom#Support_applications

https://en.wikipedia.org/wiki/Songbird_(software)

If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.

https://news.ycombinator.com/item?id=7601083

>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]

https://news.ycombinator.com/item?id=20140349

>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]

>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).

>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.

>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.

>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.

>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.

Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.

https://news.ycombinator.com/item?id=34227548

>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.

>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]

>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you. And as we all know, Android is as important to Google as iOS is to Apple.

>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.

Sadly you had to know the underlying structure of the components to work around the performance issues. Main pain point I had to work around was the fact that most containers where scrollable by default and brought a huge update cost. For a time my job was to convert components written by a visual developer in mxml into custom components written in AS3. I knew the runtime model pretty well and was able to layout complex components in code. These had the benefits of not being nested into multiple UIComponent containers/component layers which all hooked into the UI update loop. Ah good times :)

Many projects have tried this approach over the years (which means it is not a bad idea).

XUL from Mozilla, Silverlight and WPF from Microsoft, Glade for GTK and many others.

You define the widgets using markup then implement the behavior in some other language.

Then came Electron, Tauri and others that piggybacked on HTML and CSS.