I have an O’Reilly book on using XUL and XPCOM to build desktop applications. For a brief time it looked like it might be a great tool for cross-platform applications, but it ended up being the electron of its day (take a simple app, add a massive memory overhead from bundling a large chunk of a browser and end up with something that doesn’t quite behave like a native app on any platform). Unlike Electron, it lacked the saving grace of being able to share the UI between native and web app versions of the same program.
I did my fair share of XUL hacking for extensions, but this is ultimately a good thing. The differences were inevitably a source of confusion in the main code base.
However, this also adds to the massive technical debt SeaMonkey and Thunderbird are accruing, I suspect.
wait, I thought the article said exactly the contrary:
nowadays most XUL is just HTML but defaulting to box-sizing: border-box and display: flex.
So, except native OS panels and menus, HTML is the UI tech that met or passed XUL, no?
One could even say (or read, in the article) that XUL’s -moz-box layout actually bootstrapped CSS flexbox.
The key part there is the ‘nowadays’ bit. When XUL was introduced, it provided wrappers for native controls and also had deep integration with XPCOM so that you could build your own components that exposed per-platform widgets and expose them easily with XUL. It was closer to a cross-platform XAML than HTML.
HTML is a very different beast than XUL. It isn’t really designed for building desktop UIs and lacks both widgets and obvious layouts. Yes, you can always fake them with enough CSS (and sometimes JS) but it’s not the nice simplicity of XUL. Android’s LU layout format is probably the closest.
Did they manage to unbreak really good extensions like the ones with vim bindings or has that ship sailed? Because otherwise no matter how nice the change may be, if you simply remove some of the best methods to customize…
I have an O’Reilly book on using XUL and XPCOM to build desktop applications. For a brief time it looked like it might be a great tool for cross-platform applications, but it ended up being the electron of its day (take a simple app, add a massive memory overhead from bundling a large chunk of a browser and end up with something that doesn’t quite behave like a native app on any platform). Unlike Electron, it lacked the saving grace of being able to share the UI between native and web app versions of the same program.
I did my fair share of XUL hacking for extensions, but this is ultimately a good thing. The differences were inevitably a source of confusion in the main code base.
However, this also adds to the massive technical debt SeaMonkey and Thunderbird are accruing, I suspect.
XUL was great and really hasn’t been met or passed by any UI tech since. It certainly could have been improved, but sadly was abandoned instead
was abandoned instead (c) Mozilla
wait, I thought the article said exactly the contrary:
So, except native OS panels and menus, HTML is the UI tech that met or passed XUL, no?
One could even say (or read, in the article) that XUL’s
-moz-boxlayout actually bootstrapped CSS flexbox.The key part there is the ‘nowadays’ bit. When XUL was introduced, it provided wrappers for native controls and also had deep integration with XPCOM so that you could build your own components that exposed per-platform widgets and expose them easily with XUL. It was closer to a cross-platform XAML than HTML.
HTML is a very different beast than XUL. It isn’t really designed for building desktop UIs and lacks both widgets and obvious layouts. Yes, you can always fake them with enough CSS (and sometimes JS) but it’s not the nice simplicity of XUL. Android’s LU layout format is probably the closest.
firefox looked better and ran faster when it used XUL for UI
That’s a blast from the past.
Congrats to everyone who worked on this. This is so awesome and a long time coming.
Did they manage to unbreak really good extensions like the ones with vim bindings or has that ship sailed? Because otherwise no matter how nice the change may be, if you simply remove some of the best methods to customize…