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.
> 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.
The only experience I've had with any of these technologies that didn't end up inducing nausea was ATL. It made COM/ActiveX tolerable for common, simple use cases. I learned the CRTP while writing ATL components and applied it in my own C++ work to some success.
It's mostly a thick layer of lip stick though, as soon as something doesn't work you start paying for building on top an epic tower of crufty abstractions.
I once did some Java EE in Eclipse. They both look mostly the same to me. A mountain of crufty crap covered with as much lip stick as it took to make it sort of flop along.
I'm sorry if I'm stepping on toes here, this is just my experience. May I ask what you're using component frameworks for these days? I spent 13 years professionally writing reservation and accounting client/server apps in Delphi but never even came close.
XUL was pile of garbage riddled with bugs. I've made Todo app in remote XUL and every 30 minutes of development I encountered some major functional bug. Idea was great but implementation was terrible. I've used many UI frameworks over the years but when I see three letters XUL, the first flashback I have are all those bugs.
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.
Even though there are still bits of XUL in Firefox, the XUL tech itself has not been maintained along with the rest of Gecko. It was probably not in much of a better state in Firefox 56 than it was back when you were working with it.
"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?
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).
I think that XUL had better layout engines, suitable for apps instead of web pages. May be with modern CSS this gap is closed. Also native controls were nice.
We had a special version of firebug used to debug firebug itself and also XUL. It was never stable enough to deploy for general use, so I get it. But it did help quite a bit to see what was happening.
Web extensions are not limited because of any inherent limitations in technology but because of policy.
If Firefox wanted they could have created a new extension system with XUL that would also have the same limitations the web extensions do. For fairly obvious reasons they decided to transition to Web tech based extensions and used that opportunity to tighten up security as well.
Whenever you have a chance to do something in a declarative way, it's the better way to go IMO. Sad to see XUL removed... newer Firefox extensions are integrated much more poorly and are slower when the browser is busy (due to JS). Probably not noticeable for one tab though.
> security considerations, that is, to protect against malicious code.
Only in the "cannot fuck up your computer" kind of way. All addons I've installed still require "Access your data for all websites", thus have full access to my online life. Thus I only install addons from sources/authors i trust, just like back when jQuery was the coolest thing.
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.
Xaml and Javafx where released within 6 months of each other I kinda expect parallel implementation rather than copying. Just form the dates in Wikipedia
In my previous job I wrote a couple of not-too-complicated apps targeting Linux in PyGTK and I found it to be pretty pleasant, except when it came to custom styling.... mainly because the styling language does didn’t seem well documented and i found it to be somewhat arcane. Didn’t stop me though and the project got done. I wouldn’t mind working with it again
It rendered GTK I believe? Which used native controls.
I used to build a Firefox addon and the things you could do were amazing -- I could render into the status bar and popup a native window fed with data from a remote server. All from an XML file and some javascript! And you could style it with CSS!
The hacks and contortions addons have to go through now just to do something like that are insane, and the results are almost always janky as fuck.
If whatever’s rendering eventually maps to native API calls I’d consider it native, and I’m pretty sure GTK does native calls. If XUL really did mimic GTK (which I’m pretty sure it doesn’t, a lot of other GTk apps had the same feel as Firefox back when most of its UI was native dialogs) then it’s the best damn mimic job I’ve ever seen
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.
Just gonna share a link here, and I imagine that you'll be able to figure out all of my comments on the whole situation by the fact that it's on top of my bookmarks - and that I use three of the Allied programs listed.
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.
With a 5,400 rpm, just the slow rotation can introduce a wait time of 11 ms. Seek time from moving the arm can incur up to 20 ms (although some of that might overlap with the rotation time). And if it's a ten year old HDD, there might be a re-read necessary.
Even if the average read time would be just 20ms per file, cutting out ten of these reads saves 0.2 seconds, which is already noticeable to humans. And that's under the unrealistic assumption that Firefox is the only program trying to read from that poor slow HDD.
On a sidenote, laptops with 5,400 RPM drives are still sold.
> On a sidenote, laptops with 5,400 RPM drives are still sold.
And in the case of Apple also 4k iMacs. They even knowingly hide it now via a (non-existing?) footnote, seemingly hoping nobody clicks the "technical specs" button.
>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.
As for XBL: as far as I understand, it was closer to Custom Elements - defined at XML/JS layer instead of with native code. In fact it was so similar that FF developers made a tool that tried to automatically convert an XBL binding to equivalent Custom Element (similar to Python's 2to3).
They get the benefits of cross platform code, but now use something that developers are more familiar with, and the can get rid of a lot of code. Big win, I think.
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)