Living in a Go Faster, post-XUL world
July 13, 2015 § 31 Comments
A long time ago, XUL was an extraordinary component of Firefox. It meant that front-end and add-on developers could deliver user interfaces in a single, mostly-declarative, language, and see them adapt automatically to the look and feel of each OS. Ten years later, XUL has become a burden: most of its features have been ported to HTML5, often with slightly different semantics – which makes Gecko needlessly complex – and nobody understands XUL – which makes contributions harder than they should be. So, we have reached a stage at which we basically agree that, in a not-too-distant future, Firefox should not rely upon XUL anymore.
But wait, it’s not the only thing that needs to change. We also want to support piecewise updates for Firefox. We want Firefox to start fast. We want the UI to remain responsive. We want to keep supporting add-ons. Oh, and we want contributors, too. And we don’t want to lose internationalization.
Mmmh… and perhaps we don’t want to restart Firefox from bare Gecko.
All of the above are worthy objectives, but getting them all will require some careful thought.
So I’d like to put together a list of all our requirements, against which we could evaluate potential solutions, re-architectures, etc. for the front-end:
High-level
- Get rid of the deprecated (XUL) bits of Gecko in a finite time.
- Don’t break Firefox [1].
User-oriented goals
- Firefox should start fast.
- The UI should not suffer from jank.
- The UI should not cause jank.
- Look and feel like a native app, even with add-ons.
- Keep supporting internationalization.
- Keep supporting lightweight themes.
- Keep supporting acccessibility.
Contributor/dev-oriented goals
- Use technologies that the world understands.
- Use technologies that are useful to add-on authors.
- Support piece-wise, restart-less front-end updates.
- Provide an add-ons API that won’t break.
- Code most of the front-end with the add-ons API.
[1] I have heard this claim contested. Some apparently suggest that we should actually break Firefox and base all our XUL-less, Go Faster initiatives on a clean slate from e.g. Browser.html or Servo. If you wish to defend this, please step forward 🙂
Does this sound like a correct list for all of you?
Il y a du thé renversé au bord de la table 
On the “don’t break Firefox” topic:
1) I presume the breaking approach would imply not supporting XUL at all and this would apply to addons too. Unless this also means autoconverting all of them too, this could be severely damaging to our addons ecosystem and it’s already suffering enough from changing APIs and abandonments.
2) Apart from Gecko, Firefox is still quite large and this would be essentially restarting, yes? In that case this would be an immense amount of effort and time.
Find an instant/incremental approach.
By “don’t break Firefox”, I mean that we should still be able to release new versions of Firefox, with new core features, new/updated front-end features, bugfixes, etc.
Unfortunately, if we drop XUL, we lose plenty of add-ons. So if we go ahead with this, we definitely need a new, *supported*, add-ons API and enough reviewers for new add-ons, to replace the current powerful-but-unsupported-and-unreviewable add-ons.
For the instant/incremental approach: I’m not suggesting solutions at that stage – truly, I don’t have anything satisfactory. I’m just trying to put together a set of criteria that can be used to judge proposals.
Apart the browser.html/servo stuff (I’m One of them 😛 ) there’s One thing that you should add:
– Firefox should be fast and responsive eventi on quote old hardware.
I say this because alla current browsers claim to be fast etc, but this is true only on modern systems and tons of ram.
Sorry for the automatic corrections
“– Firefox should be fast and responsive even on quite old hardware.”
Would you care to elaborate? My personal feeling is that, if we try to write a new browser, it will take us at least 6 years of work before it becomes usable.
The point is: is that time so much compared to the time spent on migrating Firefox from XUL to whatever it will be?
And what’s the point? 1-3 years spent on that task (and resources moved for it) and after a few years we should however move towards what the Servo project is doing… A bit weird IMHO
“XUL has become a burden: most of its features have been ported to HTML5”
What would the standards-based replacement for XBL be? Is there any consensus around that?
Theoretically, that’s Web Components. However, there are also lightweight implementations of HTML5 components, such as React. They handle most of the burden of components – except hiding DOM nodes.
Certainly if it’s not web components, then (for better or worse) that’s not a vote of confidence in that API 😉
Starting with user needs like this is the way to go. I think it needs to go further though, and the start again discussion is closely related.
If there are substantial features in firefox today which wouldn’t make a current list of user needs, then a big part of the discussion is what to do about them.
There are at least a few approaches:
– Migrate everything from XUL to HTML
– Remove old features soon, minimising the migration effort
– Remove old feature later, with possibly higher costs
– Develop a parallel browser without any of these legacy features. At some point, migrate users from XUL-Firefox
– Migrate things that will definitely be required in the future (eg history) to in-content HTML apps and defer the decision a bit.
Some examples of ‘features’ without clear, current user needs:
– Does firefox need a set of preferences panels similar to today?
– Is tab groups a built-in-thing in the future?
– Are page-info and view source things which should go in devtools?
– ftp – it’s not secure, and likely not widely used
Finally, I’d call out this need (which could be satisfied in a number of ways):
As an add-on developer I want a stable API as soon as possible so that I minimise the amount of code I have to migrate in the future.
As a Firefox dev and former add-on dev, so do I.
– Does firefox need a set of preferences panels similar to today?
Yes. Absolutely yes. I’m tired of this “dumbification” trend seen these years.
– Is tab groups a built-in-thing in the future?
Tab groups isn’t useless. It’s the Firefox implementati in that simply suck
I wasn’t arguing for dumbing-down, I was reflecting that perhaps the functionality that is currently in these panels might be more usefully exposed in-line in the interface. eg password manager and cookie management made available via the site doorhanger.
On the tab groups point, I’m challenging that it’s a common enough user need that it would be added today. If it isn’t, then it could well be better implemented as an addon by a community which really cares about it.
In my opinion any step taken should take into account that there are users of Gecko/XUL outside of Firefox (Mozilla) where this is not limited to Thunderbird and Seamonkey.
Also the strengths of XUL should be part of the new “Gecko” platform (i.e. speed: https://enndeakin.wordpress.com/2015/07/13/comparing-flexible-box-layouts/ and extensibility)
I’m also somewhat sceptical about HTML5/CSS being able to replace XUL/”XUL-CSS” completely without having to have Mozilla (Gecko) specific definitions…
Yes, I believe that, if we migrate to HTML5, we will need Gecko-specific definitions. Hopefully just a few, though.
I just hope that we will slowly replace XUL with HTML instead of jumping to native-toolkits. Two reasons:
1) We already bank on the Web. Why not push it forward to match our needs for Firefox and make the Web stack more powerful?
2) We have the whole infrastructure to support Web stack – QA, localization, security etc. Supporting native toolkits we have nothing.
Agreed on the principle, but I didn’t intend to discuss solutions in this post, just criteria for evaluating them. If you wish to offer a solution, don’t hesitate write your own blog post 🙂 You’ll have more space to elaborate.
Personally I would like to see more about why we should spend the resources to get rid of XUL vs say polishing user-facing features. I know that everybody is all “wooo let’s get rid of XUL” but personally in my time hacking on Gecko I haven’t run into any problems that would be solved by getting rid of XUL. Can somebody point me to an actual concrete list of things that getting rid of XUL would unlock, or areas of code that would be significantly easier to work on? I’m just hoping this doesn’t become more ammunition for users to slam Firefox (“why are you guys wasting your time on this when the crash rate is so high, etc.”).
We have several issues with XUL. For one thing, we don’t want to reimplement XUL in Servo/Browser.html, so we know that it will need to die within a few years. If we wait until the transition to Servo to find a solution, this may delay the transition by several years. For another thing, we are now supporting two layout mechanisms in the same engine: XUL and HTML5. That makes the code of layout way more complicated (and bug-prone) than it should. Finally, it’s easier to find contributors who understand either HTML5 or native toolkits than XUL.
Not a contributor, just a very long time observer, but I’d like to pitch in some thoughts.
The list looks good. If it took 3+ years to remove XUL (because of add-on support and everything else), I think I’d suggest waiting for Servo/browser.html. (It’s remarkable the progress they’ve both made in quite a short amount of time, on very experimental foundations.)
I’d also be inclined to add a 3rd category ‘Society-oriented goals’ — because that would cover externalities (i.e. people who don’t necessarily use the software, but could be affected by it). That would include: Use open and transparent technologies; Use technologies that encourage learning and engagement; Create software that shrinks the gap between developers and users (between creators and consumers); Use and *improve* standardised technology that everybody else uses (ala Gaia APIs, etc.); Provide excellent accessibility support.
Some of that is covered by the contributor/dev-oriented goals (I particularly like the last one), but only implicitly. Also, if the front-end ended up being native, it would be disappointing, but I think not fatal to the web cause. (I think WebAssembly might be fatal … that’s another story 🙂 )
Also, I think Servo/browser.html should be treated as the next gen. browser from Mozilla. That doesn’t mean dropping Firefox for a very long time. But the huge amount of good-will and attention and also new grass-roots supporters (who feel like they’re getting in on something cool, new and important from the very beginning) could do a lot to rekindle many people’s interests in Mozilla. (Ala Phoenix.) And it’s a pretty fantastic back-up plan, if things can’t get sorted out for Firefox quickly.
On that topic, see the response I gave kats.
I’ll need to ponder that, but it sounds like a good idea.
Agreed. After all, the back-end is already largely native.
Agreed.
I work for a small company with a large XUL codebase (actually, remote XUL) which is used in our customers’ intranets (sometimes referred to as “XUL dark matter”). We would love to migrate away from XUL/XBL, but we really need Web Components to become a viable solution in order for us to do that.
We won’t migrate to React or other non-standardised technologies. Equally, we don’t want to jump into Web Components until there’s more consensus and it’s available by default in Firefox as well as Chrome. We were bitten in the past by an aborted migration to XBL2 when we foolishly believed the hype that it was going to be implemented natively in browsers.
I’m not against losing XUL/XBL, but please get the replacement lined up and working *first*.
Ideally Mozilla would also create a set of web components that act as drop-in replacements for some XUL widgets (as far as is possible) – particularly XUL trees, which still don’t have a functional equivalent in HTML. That would make it much easier for existing XUL developers, whether they’re working on dark matter or add-ons, to migrate their existing code to a standards-based HTML solution.
I understand quite well. At the moment, Web Components are a risky bet. Plus they are not a replacement for XUL (only for XBL).
Well, we’re definitely not dropping XUL/XBL until we have a replacement for Firefox 🙂 And we’re not there yet, far from it.
Personally, I don’t think we can get away without having at least replacements for trees, popup menus and tabs. Whether our replacements are HTML-based, native, or even something else remains an open question.
This is so silly. HTML isn’t an interface language. You can slap on all of the CSS you want and it’s still terrible for interfaces. Maybe you guys should start by making recommendations to actually FIX HTML to make it more like XUL before jumping ship. Despite many people’s feeling about XUL, the TRUTH is it is actually a MUCH easier and more flexible language for building interfaces and addons than HTML. A few really important things you would be loosing without XUL that would make building interface and addons more painful for no real gain:
– VBOX/HBOX with orient property. Nothing in HTML acts like this and can flip orientation seamlessly and pack elements and flex.
– Flex. Float is not an answer.
– Grid. Tables are deprecated in HTML. Grid doesn’t work great but there is no real good replacement in HTML.
– Custom radio and checkboxes. Forget it. You can’t restyle them in HTML.
– Any property on any element. Good luck appending custom properties to elements in order to store values or change appearance. HTML has huge restrictions on what elements are allowed to have what properties and it makes it a huge pain in the behind to use.
– Any element inside of any other element. HTML has restrictions on what can go inside of what, mostly for academic “semantics” reasons that makes building certain interfaces needlessly convoluted.
The answer to the above semantic restrictions in HTML is largely to just build everything out of DIVs and modify it with CSS to force it to act like the elements you want to use. Which means you will have to build use libraries of classes that simulate real elements. Which is ridiculous. You’d be better off switching to XML which for all of it’s problems at least it has some of the flexibility of XUL.
Note that I never mentioned that we would be jumping ship to HTML. For the moment, we have not decided what would replace XUL, we do not have a calendar, and we do not have anybody coding on this. I’m just trying to come up with a list of things that we really don’t want to forget while we’re thinking of a replacement.
Now, if we decide to jump to HTML, we will of course need to improve HTML beforehand. We might for instance end up introducing a few custom mozTags (e.g. <mozMenu>, <mozList>, …), and trying to get them standardized.
I have to agree with pjdkrunkt, as XUL is much more oriented to creating a user interface where HTML still is meant to create documents.
Replacing XUL with a native interface seems very bad to me as you then have to create the same/similar interface for the various platforms supported by Firefox.
Somehow replacing XUL seems a strange solution, especially as it underpins the extensibility of the browser (e.g. XUL overlays) and this should be duplicated in the XUL replacement as well. (And we definitively should prevent the failure faced with APNG – where a solution was created for a problem Mozilla did cause themselves by removing MNG from Gecko).
It may be an idea to create a combination of XUL and XHTML “XUHTML” were you really get te best of both worlds – and finally when I’m (still) reading blogposts indicating that XUL is better suited for a user interface then replacing it with something elso looks much, much too premature to me.
Indeed, HTML5 is not entirely ready to replace XUL. Overlays are not the main issue – we can easily reimplement them using JS and HTML5, but there are a number of annoyances, e.g. popup menus.
So, if we go towards HTML5, we will need to extend HTML, definitely.
I guess you do realize that by throwing out XUL, you will lose 90% of the current add-ons (most likely the community as well). An I can also bet that the new UI will look even more “chrome-y”.
Yes, we are aware that this will kill many add-ons. Unfortunately, we cannot keep forever in our tree a technology that we don’t maintain – and that we clearly won’t port to Servo or Browser.html.
“most of its features have been ported to HTML5”
That depends on your definition of ported. How much is built-in to the browser, how much needs a third-party library, and how much needs a third-party library but still isn’t as good as XUL?
Certainly, some features require libraries. This is also the case with XUL. If the libraries are not good enough, then perhaps we should contribute to them, instead of clinging to an unmaintained proprietary technology.