I’d like to reiterate that the one thing that makes Firefox so beloved to its users (we can all see the level of emotional investment people have in this debate) is its customizability. Some people don’t care that there is a huge world of features out there, all they want is a URL bar and a point-and-drool interface. Chrome is perfect for those users, and you cannot unseat Chrome from that throne because those people are already invested in Chrome, Chrome is noticeably faster, and is backed by the Google brand. Just like people who were already Facebook users saw no reason to switch to Google Plus.
Then there are the users who do care about things beyond a URL bar. The ones (like me) who may complain about the performance and lagginess, but still stick with Firefox because of one thing and one thing only: the customizability.
I don’t think Mozilla developers/designers have a clear notion of exactly how people use their product, so here are some examples of the customizations I use:
- The theme. I dislike wasting space, fat tabs, big buttons, rounded corners and gradients. Using XUL/CSS, I can remove all the cruft and make it look exactly the way I like.
- Stylish is an invaluable addon. However, it doesn’t provide a way to toggle styles using the keyboard - instead, you have to take your hand off the keyboard, move the mouse, click on the icon, move the mouse, then click again. With the current XUL system, I open overlay.xul, copy and paste three lines of code, and I can toggle styles with keyboard shortcuts, and even open the editor with another shortcut.
- I really dislike the URL bar drop-down which shows every item in two lines with highlight boxes around the substring matches. I find this visually noisy, wasteful of space, and too distracting. Using XUL/CSS, I can restore the old URL bar drop down where one line contains one row of data, period. I can also style the highlight to be a simple text color instead of a box background.
- Some of the popup menus have too many options when I only ever use a few. With XUL/CSS, I can remove the options I don’t use, and make the most-used items use a larger font and much more padding so that I can click them quickly and reliably.
- Because Firefox (still) has a menu bar, I can do things like set up my bookmarks/bookmarklets so that I can use the keyboard to invoke them. For instance, I have a bookmarklet “Show Document Structure” that’s very useful for web development. To invoke it, all I have to do is Alt+B-I-S (Bookmarks > Inspect > Show Document Structure). Similarly “Analyse element” is Alt-B-A.
- I just love that I can add and define my own search engines in the search bar. The decision to make it a touch-friendly, non-theme-friendly “tappable” dropdown was a huge mistake. For now, I can change that behaviour back to the old way where I can choose a search engine using Ctrl + up/down arrows and Alt + up/down arrows. I really hope that option stays.
- I use a status bar addon (Status-4-Evar) to see where a URL leads, download progress bars, various status icons, the IP address of the website I’m on, etc. The decision to take away the status bar and not even have it as an option was one of the worst blunders in Firefox history.
This is all just to give Mozilla developers and designers an idea of how people are using your product. I’m certain other people have their own, uniquely personal setups. If you switch from XUL/CSS to an API-based approach, please try to keep this level of customisability available.
You should be thinking how to improve the customizability, instead of crippling it. Everything is moving to the browser these days, and a lot of people see the browser UI more than they see their operating system UI. Every sane product like that offers customizability - on my smartphone I can choose which apps/settings to put on my start screen, which icons I see in the notification bar, the color and size of my tiles, etc. In the Drupal CMS’s admin section, you have a toolbar that you can drag your most-used items to. Deciding to remove user choices is a giant backwards leap for Mozilla, and a huge loss for mankind.
I’ll say it yet again, because it bears repeating:
If Firefox becomes a slower clone of Chrome, why would people use Firefox at all?
The only reason I can think of is if Firefox became significantly faster than Chrome, which I think is unlikely to happen because Google has a lot more dollars to throw at development. You cannot beat Chrome at that game. The only thing you can do is play to your strengths. The C-word. Customizability.
I understand that it’s hard to support a browser that is so customizable. So don’t! Tell users up front that you can only support the vanilla browser.
For a long time I’ve been getting the strong impression that Mozilla developers are tired of maintaining the existing code base. Removing features, dropping Thunderbird development, the push for automated addon verification, all indicate a general weariness that’s been building over years.
The real problem here is code quality and code bloat. Mozilla’s own theme XUL/CSS is horribly bloated and monstrously complicated. Burn it to the ground and start over. Keep it lean, clean, and simple. Throw out the obscenely complex CSS selectors (see my post above). If you’re writing CSS even one-tenth as complicated as that, you’re doing it wrong. Why do you need a bazillion elements to represent a simple tab/button? Is the “feature” of having overlapping S-curved tab edges and sliding tabs worth so much extra code and the resulting performance hit? I’ll bet if you removed all those frills and the UI became noticeably snappier, users wouldn’t even notice that their tab edges don’t overlap any more and would be happier.
I still keep a copy of Firefox 3 around for comparison. Every time I fire it up I’m blown away by how responsive the UI is - try it sometime. Because the performance drops have been so gradual and cumulative, I think Firefox devs have forgotten how snappy it used to be - the UI responsiveness is native-like. Not just the UI - scrolling is very noticeably faster than any recent version of Firefox. I understand that some of this may be because FF3 doesn’t support fancy new web features, but most pages don’t use those features.
Firefox 3 used XUL/CSS, so why is it so fast? To me, it indicates that the problem is not XUL/CSS, but badly written XUL/CSS that has gotten bloated and overly complicated over the years.
##XUL? HTML?
I really like the idea of switching from XUL to HTML. The idea that the UI becomes essentially a fixed-positioned overlay div above/around the content is beautifully elegant. Instead of having two engines, one for the UI and one for content, you could have just one. Save developer time, reduce the size of the codebase by a huge amount, and save CPU and RAM usage into the bargain. For addon/theme developers, not having to learn another language is a huge plus, and for Mozilla, being able to tap into the much larger talent pool of web developers (compared to the Firefox themer talent pool) is another.
The only thing I would change is that instead of using generic <div> elements with classes and IDs, I’d use custom elements and have all the basic styling/functionality defined in native code instead of CSS/JS, with themers only being able to change the cosmetic values. So, for instance, instead of a long nested list of <hbox>es and <vbox>es we’d have
<tabs>
<tab>
<tab-icon />
<tab-text />
<tab-closebutton />
</tab>
...
</tabs>
Instead of the truly horrible code that is the XUL tree and its associated styling, use tables as Antoine suggested above. What exactly do trees provide that tables don’t?
Make a list of all the properties that are CPU-intensive, and remove support for them in the UI rendering engine. If an addon developer uses those properties, either throw an error, or silently ignore them. There’s no need for, say, drop downs to have animated box-shadows and blur effects. Keep the UI rendering engine as lean as possible.
Having addon authors create their own widgets is a huge waste of developer time and an invitation to badly-written (at least in part) addons - a developer who may be great at JS may not be very good at CSS/XUL, and the widgets he builds will probably be ugly and badly-written. So for instance, instead of a bunch of addon developers each creating their own implementation of a progress bar, give them a progress bar widget:
<progressbar-wrapper>
<progressbar-icon />
<progressbar />
<progressbar-text />
</progressbar-wrapper>
This way, the developers who do want to define their own widgets can still do so, and the ones who’d rather not can use the built-in ones.
Another example: Stylish has a built-in code editor that is not only nowhere near as good as a native code editor, but completely pointless, and a waste of the developer’s time. If an addon needs an editor, why not let the user specify their own code editor and have Firefox interface with that? User clicks a button, Firefox creates a temp file and passes it to, say, Sublime Text, and updates its internal copy whenever the file is saved. The user gets to use their favourite, familiar code editor with all features. Addon developers can focus on their actual addon features instead of reinventing the wheel.
I’d also strongly recommend having the editors in Developer Tools, View Source, GCLI etc. be a native implementation. Why exactly do we need XUL for that? It’s completely unnecessary, inelegant, and immensely wasteful of CPU and RAM.
##To sum up:
- If any fancy-pants designer says they need to change the XUL yet again to implement their latest, greatest aesthetic inspiration, slap them
- Menu bar good, status bar good, more options good
- Removing features bad
- Clean up the code
- Simple CSS selectors good, complex selectors bad
- Lean XUL good, complex XUL bad
