Live data from Hacker News

No XBL Components Left in Firefox

twitter.com

41–50 of 73 posts

Re: No XBL Components Left in Firefox

#41
Back in the early 00s I was actually shocked that no one attempted to make a desktop environment, or at least applications, using XUL and Gecko. Sure there was Chatzilla but I never saw like a file browser, or an mp3 player.

Now we have Electron and all my wildest dreams came true.

Re: No XBL Components Left in Firefox

#42
post #25
post #5

Earlier quoted context omitted.

What is the closest thing we have left that is close to “mostly declarative GUI”? QML? Tk? Please don't say Electron.

XAML, but it Microsoft-specific. While not completely uniform its use does extend across desktop and mobile. I wouldn't make the argument that it's intuitive or simple, but it is powerful.

WPF is open source[1], but there isn't any effort to port it as far as I know. WPF also had a few warts compared to Silverlight.

[1]: https://github.com/dotnet/wpf/

Re: No XBL Components Left in Firefox

#43

Earlier quoted context omitted.

"HTML5" + things like css grid and flexbox that you need to build UI in a sensible manner are pretty new inventions. XUL predates them dramatically, building UI in HTML at the time would have been an absolute nightmare. I know because I had to ship it in multiple applications

I understand that it probably was a better technology at the time. But are there any concepts/technologies in XUL that would be useful to add in the HTML standard?

It's a minor problem, but CSS, unlike XUL, doesn't provide a way to crop text in the middle[1][2].

[1] - https://www.w3.org/wiki/Text-overflow_middle_cropping

[2] - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...

Re: No XBL Components Left in Firefox

#45
That's a non-trivial amount of hard work going down the drain right there.

I'm not saying it was the right thing to do, but XUL and the component architecture were major reasons Mozilla took forever to be released, and then forever again to become usable.

And then a major reason why Firefox extensions became a thing long before using web tech was an option.

I tried to find uses for it back in the days, read a book and played around with it. What killed it for me was hooking into C meant dealing with Mozilla's internals a lot more than I would have preferred. These days serverless is common, but back then it was practically unheard of.

I did use Songbird [0] for a while, but it was always slow and buggy for me. And it never really went anywhere, not for a lack of trying from the looks of it.

ActiveX, Corba, Bonobo; they always seem to get so complex and bloated that no one wants anything to do with them when there are other options.

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

Re: No XBL Components Left in Firefox

#46

Earlier quoted context omitted.

That's surprising. I wrote an extension back in the days, I think it was Firefox 1.5, I used XPCOM to use C code and it worked well. I don't remember stumbling into too many bugs. Actually I liked XUL and I thought that it has great future, because it was so much better for UI than HTML.

Would you care elaborating why it is better than HTML5?

HTML5 (2014) and Firefox 1.5 (2005) were not contemporaneous.

Re: No XBL Components Left in Firefox

#47

Earlier quoted context omitted.

I understand that it probably was a better technology at the time. But are there any concepts/technologies in XUL that would be useful to add in the HTML standard?

It's a minor problem, but CSS, unlike XUL, doesn't provide a way to crop text in the middle[1][2]. [1] - https://www.w3.org/wiki/Text-overflow_middle_cropping [2] - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...

Cropping text in the middle is extremely hard to spec and implement for general inline CSS. Cropping at the start or end can be implemented as a purely paint-time operation. Cropping in the middle means you have to change the layout, and you have to define the layout of the stuff in the middle that has been cropped away in case someone does element.getClientRects() etc. It is far from obvious how that should work.

XUL texboxes avoided this problem by only supporting a single plain text string, but applying that constraint to HTML+CSS would be incredibly ugly (and people soon be complaining about that constraint, anyway).

Re: No XBL Components Left in Firefox

#48
post #37

Earlier quoted context omitted.

userChrome.css still works, and if you already had one they automatically flip the pref on for you. It's default-off because it increases startup time.

I wonder, what's the 95% worst case latency for a stat on a 5400 RPM laptop drive from 10 years ago? Assuming of course that the drive is already spinning since it's reading a million other things from your profile. I bet it's negligible in almost every case.

A single file open and close isn't that much, but dozens or hundreds of these tiny performance papercuts add up and make application startup slow.

Re: No XBL Components Left in Firefox

#49

If I understand this correctly, do they mean Firefox desktop GUI is rendered using HTML elements? I understand chrome UI controls are based on skia. If yes, is this available as some kind of framework that can be used to develop custom desktop applications (like Qt)?

Getting rid of XBL is a big and good step, but XUL is still being used. They're working on getting rid of that too. It's not all HTML yet.

Re: No XBL Components Left in Firefox

#50
post #23
post #2

>And now a major browser's UI is built with web components! Proud that you need to use your HTML/JS engine to render your UI instead of using faster native code? I mean you have the opportunity of getting rid of XUL and instead you change it... for something similar?

The browser UI was already rendered by Gecko, that's how XUL and XBL work. It's just that it's rendered by parts of Gecko that aren't used by anything else on the web, and so in honesty those paths probably had less optimization, not more.

That sounds like a great thing, because the Web is where we applaud people if their site renders in a second, enough time for a modern processor to render a full fricking playthrough of the original Doom.
Post reply on HN