[espadrine]

XUL was a weight on developing for Firefox. It worked like HTML, but was nonstandard. At first, it meant they could quickly implement things like flexbox (<hbox> / <vbox>) and gridlayout (<grid>) long before they were a thing in CSS.

But as HTML and CSS slowly got more features than XUL, XUL development slowed down, up to the point where writing the Firefox UI in XUL became a pain because of poor tooling and sneaky bugs. More and more pieces of Firefox got written in HTML inside XUL, and factorizing code between the pieces in XUL and those in HTML was nightmarish.

Dropping XUL means putting those bugs and issues behind us, and focusing development on a single DOM language. You would probably be surprised by how much of the UI already is in HTML; tab groups is almost all HTML, and the DevTools' editor and DOM inspector are in HTML as well.

As for donating to Mozilla, the distinction between Mozilla Corp and Mozilla Foundation is understandably complex for outsiders, but basically only Mozilla Corp makes money from the partnerships.

[emidln]

> It worked like HTML, but was nonstandard.

Being nonstandard is completely irrelevant here. Firefox's UI doesn't need to be rendered by Internet Explorer or Google Chrome.

[scrollaway]

Much as i despise HTML UIs (see reasoning my rant below https://news.ycombinator.com/item?id=10655606), it is relevant and XUL is horrible.

I'm glad to see it disappear, it's one of those things the world doesn't need. A failed experiment. And an HTML UI for firefox makes sense in the long run.

Fun fact of the day: Did you know XUL uses DTD to store translations? That's right, if you have a string you want to translate, you just have to create a new XML element in a localized DTD file. Isn't that just a wonderful idea.

[DonHopkins]

I was just going to mention that, but you beat me to it. It's just bizarre to use XML external entities for internationalization.

I worked on TomTom Home, which was implemented in xulrunner, and I developed some internationalization/localization tools that had to deal with XUL DTDs as well as several other different and incompatible file formats for storing translations. I could never for the life of me figure out why they decided to use DTDs with external entities for translations.

[ZenoArrow]

XUL wasn't a failed experiment. From what I understand it served as the inspiration for some of the new features found in HTML. If that's the case it was a useful experiment.

[mercurial]

What do you think is so horrible about XUL, apart from XBL being really, really verbose? The basic UI part is fairly decent, IMHO.

[espadrine]

> Being nonstandard is completely irrelevant here

It was meant as a pro. Since it was their own language, they could do anything with it. They could make a better HTML.

But HTML caught up. Currently, I believe HTML is better than XUL, and making XUL great again is both a silly reuse of a political slogan and a waste of effort.

I for one would rather see efforts made to allow CSS styling of all input elements in HTML.

[ultramancool]

Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform. This is completely lacking in any HTML based UI I've ever seen. It's been a major advantage for FF extensions and I can't help but feel like it's a major step backwards to lose it.

[pcwalton]

> Good luck - the main advantage of XUL IMO is that it looks and feels native to the platform.

That you say that is a testament to how well the meticulous CSS styling of the XUL elements—which applies equally well to HTML (try it in a browser chrome shell!)—worked.

[digi_owl]

I don't think that has anything to do with XUL directly, you can still find its original look by furing up Seamonkey, but that Firefox developers opted to rework the UI subsystem so that it translated XUL elements into native elements as much as possible. Iirc, this was done in part to speed up the Firefox UI compared to Seamonkey.

[masklinn]

> Being nonstandard is completely irrelevant here.

It's relevant in that much of the work has to be duplicated (documentation but also layout implementation & the like) and none of the new and improved web development tools can be used for XUL.

[realusername]

The problem as I understand is more about the documentation, the hidden quirks and also the barrier to bring new contributors to the source code. It's always easier when they don't have to learn a custom language first.

[pcwalton]

> Being nonstandard is completely irrelevant here.

No, it's not irrelevant. Standards are also about documentation (it's easier to document standardized things) and familiarity (people are more familiar with standardized things).

[janvidar]

It is not entirely irrelevant.

Given that there are more developers familiar with HTML development, it may lower the barrier to developing plug-ins, or providing patches.

[emidln]

I was poking at the non-standard portion. Lowering barrier to development of plugins, patches, etc is fine, but being standard doesn't help or hinder that. Popularity and ease of introduction help that. Javascript (that is, the dialect of ECMAScript that is implemented by Firefox) itself is non-standard and Mozilla isn't throwing that one out for exclusively ES2015.

[pcwalton]

Actually, tons of nonstandard SpiderMonkey features have been removed. Sharp literals were axed, E4X was removed, "let" is being changed to the ES6 behavior, and so on.

[gsnedders]

FWIW, there are real intentions to standardise all the JS extensions or drop them.