3 ms·

I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun.

I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun. XUL is 25-year old legacy technology, and using it is an exercise in retrocomputing.

jd3 5y ago
Fair enough. Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`. I have been experimenting with performant lists (which is why I brought up the XUL tree — it's currently central to the interface, though not the final implementation for sure) — I'm currently only using the XUL window/menubar elements in order to populate the native macOS menubar. I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc. I love gecko and used to write XUL add-ons many years ago, so I'm already familiar with JS code modules, XPCOM, XUL, the internal browser architecture etc. Basically, I'm now using XULRunner (`firefox --app application.ini` as previously mentioned — will eventually be stubbed into a native macOS .app/OS program) as a replacement for Electron / Chromium Embedded Framework[1]. I'm basically doing the same thing as Positron[2]/qbrt[3]. [0]: https://preactjs.com/ https://preactjs.com/ [1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework [2]: https://github.com/mozilla/positron https://github.com/mozilla/positron [3]: https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt
girvo 5y ago
While you're definitely correct, I enjoyed working with Komodo IDE which was (is?) built around XUL even up to a few years ago. A neat API for extending and hacking around on it, with quite nice discoverability. I'm sad to see it go, but it makes perfect sense as to why!
silon42 5y ago
Probably still better than anything HTML.

jd3 5y ago

Fair enough. Sorry, I should have clarified a bit more — I'm writing a cross-platform desktop application that has a preact[0] frontend (+ a Go backend) using `firefox --app application.ini`. I have been experimenting with performant lists (which is why I brought up the XUL tree — it's currently central to the interface, though not the final implementation for sure) — I'm currently only using the XUL window/menubar elements in order to populate the native macOS menubar. I am a fullstack web dev in my day job, so my goal here is to write a fast, easily extendable UI that I can quickly iterate upon using modern html/js/css/etc. I love gecko and used to write XUL add-ons many years ago, so I'm already familiar with JS code modules, XPCOM, XUL, the internal browser architecture etc. Basically, I'm now using XULRunner (`firefox --app application.ini` as previously mentioned — will eventually be stubbed into a native macOS .app/OS program) as a replacement for Electron / Chromium Embedded Framework[1]. I'm basically doing the same thing as Positron[2]/qbrt[3]. [0]: https://preactjs.com/ https://preactjs.com/ [1]: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework [2]: https://github.com/mozilla/positron https://github.com/mozilla/positron [3]: https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt

girvo 5y ago

While you're definitely correct, I enjoyed working with Komodo IDE which was (is?) built around XUL even up to a few years ago. A neat API for extending and hacking around on it, with quite nice discoverability. I'm sad to see it go, but it makes perfect sense as to why!

silon42 5y ago

Probably still better than anything HTML.