Some context that might help people understand this email...
There are two high-level components which make up Firefox. The first is Gecko, the rendering engine. The second is Firefox, the application itself, which uses Gecko to render Web pages and itself.
Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).
What's going on here is that Mozilla is considering getting rid of XUL and XBL and building Firefox with the same technologies that people use to build Web content.
There are at least three big advantages to doing this:
1. Eliminate the need to support XUL and XBL in Gecko.
2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.
3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.
The only real downside is the amount of work involved.
Could this potentially be a first step towards eventually replacing Gecko with Servo? If Firefox (the application itself) eventually resembles browser.html [1], swapping out Gecko for Servo would be much easier.
If that were to happen, how big an impact would that have on Firefox OS development? I admittedly don't understand the project too well, but they had to port Gecko to work in Gonk right? Would there be significant overhead getting Servo working under Gonk?
- currently browser.html runs on top of a gecko runtime (called graphene) which is based on the one we use for FirefoxOS.
- getting gecko to work on gonk is not different from adding support for other platforms like linux/mac/windows/android. Basically you need to provide implementation for low level windowing and input events. On non-posix systems there's a bit more to do in the nspr library, but that's not the case for gonk.
- we already have a port of servo that runs on gonk.
FirefoxOS has been using a 100% html UI since about 4 years, so it has been leading the way here.
It would certainly help us port Firefox to Servo. But that's never really been a part of the plan.
Gecko and Firefox are quite intertwined. Even if we ignore XUL/XBL, there are things like XPCOM which are still deep-rooted. While this brings us a step closer to making Servo a drop-in for Gecko, this is not a step in a direction we're particularly interested in. At least not now, not that I know of (I'm a volunteer on the Servo team, as such there may be internal plans I'm not aware of).
For Servo one potential way ahead is bringing browser.html up to Firefox's level. Not the other way around :)
I agree it doesn't make sense for Servo to be a drop-in replacement for Gecko, but that doesn't mean we shouldn't bend Firefox towards compatibility with Servo. A future Servo-based Firefox is far enough off that it's impossible to predict every step from here to there, but if you ask me, dcamp's email is on the right track: we should evolve Firefox away from dependence on non-standard tech like XUL, XBL, and XPCOM and towards self-hosting on standard web technology and taking full advantage of everything Servo has to offer. What that looks like in practice remains to be seen.
I agree. A key point to achieve that is to define what the embedding api looks like. Right now on FirefoxOS it's partly the mozbrowser api for iframe-centric features, and partly custom events that are dispatched on the top level "chrome" iframe. There's still some cleanup to do there ;)
Of course. I'm just saying that from the point of view of Servo, drop-in Gecko isn't really the focus. Making Gecko more HTML-y is a great step for Gecko, but from a purely Servo point of view at the moment it's not really something tangible. Though you're right, it may mean something for Servo a couple of years from now.
The Firefox (Desktop) UI is already rendered using Gecko. It has been that way since the beginning.
Mozilla spends much more time optimizing HTML and other Web content tech than it does optimizing XUL and XBL. I wouldn't worry too much about this project slowing down Firefox. It might even speed it up a bit.
The e-mail seems to suggest that it would improve performance.
>Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the web, and that doesn’t help anybody.
I believe that's already the case, although it uses XUL-specific code paths in Gecko.
In terms of performance -- there is no deep reason for it being slower, but of course the code might end up being a bit less optimized compared to stuff that has been battle-tested for 15 years. On the other hand, getting rid of XUL could deliver dramatic results. It's all speculation really, but there is no real technical reason for "XUL-less FF" to be incredibly slower than current offering.
Another advantage that's not immediately apparent is that it would also open up changing the rendering engine. I think the firefox mobile browser is actually using this to do the main UI on android at least. Along with that there's the browser.html that Servo is using as a base for the browser chrome.
I can't imagine that Firefox on iOS will actually be that useful. Half the usefulness of Firefox is the extensions which I think would violate the store rules on iOS wouldn't they?
The primary usefulness I would see is syncing your browser history, bookmarks, etc. across devices. I use Safari and I have pretty much every extension I feel like I need.
Not sure I understand your question, but the thing I'm talking about is a new "Firefox for iOS" product being worked on right now, due for release pretty soon IIUC, that will include syncing among its core capabilities:
I wonder if there could be some collaboration where firefox, chrome, safari, IE, opera, etc. can exchange and sync - possibly too much to deal with, and might hurt innovation.
Firefox is my primary browser everywhere but on iOS. It would be nice if I could have the passwords, history and bookmarks available to me on all my other OSes on iOS as well.
Will this lead to loosing any of the flexibility in configuring Firefox (all variables you can find in about:config) that is so useful when using e.g. vimperator or pentadactyl?
Plugins are the only reason I use Firefox over any other browser.
Can you explain to me why Firefox would be better off if I didn't have Rikaisama for my Japanese studying or one of a number of Youtube plugins that make the site bearable again by forcing annotations off and 1080p on.
This is most likely an addon, a Firefox extension written in (mostly) JS and XUL. Plugins are the external runtimes embedded in browsers with NSAPI &al: Flash, Java, Silverlight, etc...
a lot of modern firefox plugins are already written this way, but there are probably a significant amount of legacy addons that would need to be rewritten
I hate the trend of building native UIs in HTML, because the result never feels right. For example, Firefox does not use OS X native context menus, and it shows in how they look, position themselves, animate, respond to keyboard and mouse events, etc.
But Firefox devs have clearly spent a great deal of effort to make these faux-context menus look native. What an enormous waste of development energy to emulate what the platform already provides!
Rather than pushing forward with a layer that provides even less access to platform UI elements, I wish they would recommit themselves to keeping the native elements native.
There's broadly two directions Firefox could go: do everything in HTML, or use native widgets. Firefox for Android initially used XUL just like Firefox desktop, but switched to native. They've had a lot of success with that. This email is the start of a discussion that will include that option.
Is there an official line that Firefox is taking on this? As a novice to their development decisions, I've always wondered this myself.
I sometimes feel like I can sense when a UI is not native; it's completely useable, and I have no functional complaint, but it might just seem...off.
I felt a small bit of delight when I switched back to Firefox on my Windows machine and saw the snappy animations for new tabs and its menus. It made a kind of subconscious difference.
I would guess that there's some functionality provided via XUL which doesn't exist in the native OSX context menus (i.e. precisely the same functionality doesn't exist, not that the native OSX context menus are somehow deficient). That's going to be particularly relevant for extensions.
I can't agree more. Where does this plan leave desktop app dev. with Mozilla technologies? There are tonnes of projects (desktop apps) using XUL, XPCOM, e.t.c. SUre, the future is the Web (like Web OS, Unity, i.e. UI in HTML). Why can't they improve on XUL/XBL by releasing a new version with the desired features while they try to simplify building extensions/apps with XPCOMs? They should standardize apps dev. for FFOS (gonk{+necko}/gecko/gaia) & FF(gecko+necko/xul). This effort does not necessarily mean spending much time on enhancing the UI for FF but rather ensuring seamless app. portability between FF and FFOS.
If you want to share the same code base you need to grantee the same functionality. The easiest and most predictable way is to run this through an intermediate and then render that intermediate. This is why compilers use intermediate representations like bytecode, you don't want to write a compiler that builds only x86 and then another when you need to build ARM. You don't want to write a rendering engine with different implementations for each widget kit.
Well, the XPCOMs represent the bytecode in your opinion. One still can't get an XPCOM for FF to work on FFoS, I meant the simplest one without making huge changes to the code base. Yes, one UI engine is needed and so is a (cross-)compiler in your case OR alteration of the code base for FFoS of FF to ensure portability. I guess it would be the FFoS code base that might need to change. BUt that could be tricky since it leverages the Andriod's core - a component-based linux OS.
The correct thing to use is AppKit on OS X, WPF on Windows, GTK+ on Gnome, and Qt on KDE. Yes, this requires more code, but it results in a much, much better experience. As an OS X user, it's so obvious when an app isn't properly using AppKit.
Firefox has traditionally not been very popular on Mac for this very reason. They've gotten better at imitating OS X slightly, but even today it's still out of the question for me (and I suspect many Mac users) to use Firefox. It feels really awful to use. Whilst Chrome and Safari have nice native scrolling, rubber banding and smooth zooming, just like any other native app, Firefox feels jarring. It only just supports gestures (there's no nice animation like in Safari or Chrome).
My day-to-day browser is Safari. Not because it's faster or technically better (it really isn't) but because it's fully native and integrates properly with the system, e.g. it integrates properly with the downloads folder (showing the progress bar on the file and on the folder icon) and it looks and feels like any other Mac app. Chrome may be faster, Firefox may be more extensible - but I choose Safari because it works properly with the OS.
I really love Mozilla and I would love to use Firefox. I really hope they go with a OS-specific native shell - although I suspect they'll go with building the UI in HTML/CSS. But if they do, there's a good chance I'll switch.
It's hard for me to believe someone telling me "if it's not 100% native look and feel it's not good" when they're trying to sell something and build a content silo.
> The correct thing to use is AppKit on OS X, WPF on Windows, GTK+ on Gnome, and Qt on KDE.
WHAT?! Personally, being asked to rewrite the UI for X different native platforms is rage-inducing.
Some people who write their apps in Web technologies have done native UIs and are sick of the duplicated effort. ;)
Well it's already been done before. Yes it's a lot of effort but the added user experience can be very valuable. Case in point: Transmission is a BitTorrent client that has at least a Web UI, an OS X native UI, a GTK+ and a Qt one. Using the app just feels right, and the little bits of joy while using just adds up.
It's just a judgemental way of saying that they have not made UI quality a priority. They're saving money on dev time by asking users to put up with a lower-quality experience, and I always feel resentful and put-upon when I encounter such an app. I'm likely to scrap it out of spite and use something else which has a better interface, even if it is less featureful.
(also, what happened to the edit link? "UKs" was obviously supposed to be "UIs" above.)
> They're saving money on dev time by asking users to put up with a lower-quality experience
I think that the idea that somehow if the UI is written in web technologies that it's somehow lesser quality is a false dichotomy. Web developers and native developers can make UIs that look exactly the same to the point where they are indistinguishable.
You have 2 hours after posting to edit a ~~commit~~ comment. Not my favorite "feature."
Well, maybe they can, but I haven't seen it happen, and it has never been truly indistinguishable in the past when people have made similar claims. Cross-platform UI tools have been coming and going for years, and "write once, run anywhere" has always been a goal and not an accomplishment. People said the same thing about Java apps, but you could always tell - there was always something that didn't fit right, and the "uncanny valley" effect makes it hard to respond with anything other than revulsion when you realize that you're working with an elaborate fake.
I'm used to agree. That's how you get a native look and feel, but I don't think that's necessarily what people want. I find the use of tabs in the browser to be very telling - it means the way OSes have handled multiple instances of an application are not satisfactory, so people want the browser to handle that. Once it's in the browser people will want it to be the same on all platforms.
Someone should survey software end users to figure out if they care about native-looking UIs. I have a feeling most users don't care very much.
My most-used GUI apps are Chrome, Visual Studio, Ableton Live, and Photoshop. All of them have heavily customized user interfaces. Their custom controls and tiling/layout systems are tailored to the application domain. Except for Chrome, these are "do your life's work" applications. They should aim for maximum productivity, even if it makes the application harder to use. I think they would suffer if they tried to "look native".
Most everything else is done in web apps these days. Users don't seem to have a problem dealing with different button CSS in different web apps.
Certain things, like the "open file" dialog, really suffer if they look non-native. But I think users don't care about most other cases.
There's nothing wrong with designing custom UI elements, so long as they're done properly on each platform. For example, Safari's tabs are completely custom (as far as I know) - they can't be used in other applications, they aren't part of Cocoa - but they're tastefully designed and they work well.
Well they're either going to have people writing platform specific code, or people writing code to emulate and keep current with platform specific features.
Agreed. I strongly dislike the philosophy espoused by the parent. "I recognize that other products are technically superior and allow me to do more things without inflicting undue hardship or learning curve, but because the animations aren't as nice, I'm just going to use this other thing." I have no interest in humoring those with such a vain and frankly indefensible perspective.
What a comment! You made a binary discussion from a nuanced one. The question is whether an attractive UI (which, surprise, matters to many people) is worth focusing developer effort. Several comments in this thread advocate that non-native UIs look tacky, and that it would do well for the product to have native rendering.
As an aside, it's the no. 1 reason I don't use Atom: An ugly, slow UI that doesn't render native elements.
So no, it's not indefensible. I think your conspirator's OP comment "As a non-OSX user, I don't care about your UX" is more vain.
> I think your conspirator's OP comment "As a non-OSX user, I don't care about your UX" is more vain.
Sure it's vain. We all have personal priorities. People suggesting that Mozilla spend time developing the perfect OS X product are expressing their priorities as well.
I could say that I'm a BeOS user and I really think that Firefox should have a fully-integrated native UX because the way a product looks and works is important. But no one cares about BeOS UX because they're vain.
It looks like OS X users are the only ones who really care. Windows users have been dealing with non-standard UIs since tabs first stopped being MDI, and, comparing Chrome's adoption with how it looks, they're mostly fine with them. Linux users are mostly just straight-up crazy and Firefox is fine for them. Smartphone users have seen more non-standard than standard UIs and it doesn't seem to have been a problem for the Facebook app. The question is then is it worth caring as much about OS X UI, or is it more useful to make a better product for the 80+% of users who don't use OS X?
In what way is this a choice between "technically superior" and "nice animations"? The reasons that Firefox, for example, is terrible on OS X is not to do with the quality of the animations (although they are awful) but rather the semantics of user interaction, which are by definition different in non-native applications.
And, I'd argue, Firefox is far, far, far from "technically superior" on any number of axes, regardless.
It's really not indefensible, and you're sort of minimising a valid viewpoint that I wish more developers took on board.
User experience is important. Dismissing that aspect as "animations [that] aren't as nice" misses an important point - things like animation, consistency with the host system, integration with platform features and so on are really very important to the quality of an app.
Technical capability is also important, obviously. It's why I use Firefox and when building web projects on the Mac - best feature set. But I use Safari instead for day-to-day browsing, because of things like better scrolling and zooming, and better integration with platform services.
I do think the way a product looks and works is important, and developers who dismiss that are why we have so many awful UIs out in public.
I agree user experience is important, but experience is so much more than simple aesthetics.
I'm not saying they're totally unimportant, which is why I included the qualifying clause about "undue hardship", but I have no respect for users that will put themselves at a functional disadvantage so that their experience can be "prettier" (aka "more native"). These people have their subculture, called "Apple", and frankly, I want as little to do with it as possible. Prioritizing glitz above function shows serious problems in critical thinking.
If we can make an application look better, cool, we should add that to the list somewhere. I'm not opposed to that. I strongly disagree that this should be anywhere near the primary criterion used to judge an application's value.
While discussing downvotes is considered bad etiquette, can someone explain why cookiecaper has been downvoted? They've expressed their viewpoint, respectfully and at some length. Downvotes because you disagree with their viewpoint is bad form.
Edited to add: And I disagree with them, however I'm downvoting to show disagreement is something that HN has always been against, to it's credit.
Because he accuses those who have different prioritization in the functional/experience tradeoff of having "serious problems in critical thinking"? It's a matter of opinion and not mental capability.
I disagree. The person that will impede his ability to accomplish actual work because of his subjective aesthetic preferences is substantially less "mentally capable" than a person that will tolerate a bit of ugliness for greater efficiency. Again, it's a matter of degree because there are some programs that are so "ugly" that they are unusable, but the grandparent's specific example was Safari v. Firefox, and while Firefox may not conform to Apple's aesthetic standard exactly, it's far from unusable. The GP admitted that both Firefox and Chrome were superior to Safari in tangible ways that affect productivity, but that they continue to use Safari because they think it's prettier. I cannot comprehend that POV and have no respect for people who hold it, and that expands outside of software too.
I can see you've decided to ignore what I actually said and instead substitute your own version.
I'll tell you what I can't comprehend – people who apparently find it difficult to accept that other people have differing priorities to them, and aren't mentally subnormal as a result.
This would result in bugs between different UIs on different platforms, resulting in duplicated effort and codebase, and many frustrated developers who want to work on feature Y on platform X, and cannot port it to platform Z because of missing support or different implementations.
I don't really care if an application is native or not, Firefox works great for me on Os X and I really appreciate I can run the same browser on all platforms I have to use or developer for.
It's probably time (past time, actually) for Mozilla to start looking into putting XUL/XBL to pasture for Firefox UI and using HTML/CSS/JS instead, since the Web platform has become sufficiently capable that the arguments for having a separate stack of technologies for building UI don't really hold anymore.
Still makes me a bit sad to see it go, though; I'm old enough to remember when XUL seemed like an exciting potential platform for general-purpose app development. Which never really panned out, alas, but was fascinating at the time.
IMO, it did pan out. XUL and XBL provided the inspiration for much of what's come to real Web standards over the last decade or so. Thanks to XUL, we had a web-like model for front end dev that over time was usurped by a real Web model for front end dev. If we can re-implement Firefox using real Web standards, XUL will have been be a big part of the reason that became possible.
That's great for FF and Mozilla, but it doesn't feel like a win for those of us who were interested in XUL/XBL as a platform for building our own apps, independent of those Mozilla ships. I put a little bit of time into trying to build stuff on top of XUL before giving up on it, and that time ended up being more or less wasted -- it's not like there was an easy glidepath to take stuff built in XUL and move it to Web standards, because back then Web standards weren't up to the task. Combine that with the platform itself being a bit of a moving target as MozSuite/FF evolved and the end result was work I basically had to throw out.
I'm not mad at Mozilla for all that, lots of platforms are complicated to build on, especially ones that are new and still evolving (which XUL definitely was, at the time). It's just not an experience that I feel like I can put into the "win" category. It was a dead end, at least for my needs.
Yeah. I hear ya. As a platform for app development outside of Mozilla projects and products, it has definitely been a bumpy and often roadblocked path.
And Web Components owe a clear legacy to XBL2 (an abandoned W3C draft, the immediate forerunner to Web Components), which obviously had clear links to XBL (though was backwards incompatible).
Yep, I remember actually building a toy 2d tilemapped RPG engine with it maybe a decade ago. It definitely wasn't capable of anything fancy then so I didn't do much more than have it let you move around the map with a simple UI around it . Now HTML/CSS/JS can completely blow it out the water with what you can do.
This email represents an intention to start investigating moving away from XUL/XBL. There are a number of areas to explore here like how to properly handle L10N, add-on overlays, and where to go native vs markup. At the same time we're actively moving over to e10s (electrolysis / per process tabs). There will be followup communication about who is doing the work and what work is being done but now is the time to add your concerns and comments or offer support.
Can XUL/XBL just be ``compiled-down" to proper HTML, or is there also a security issue in that Gecko allows XUL/XBL to break rules needed to securely render HTML?
That's a good question. I don't know the answer, but I'm curious as well. If it is an option, might be a good interim solution, perhaps not for the main UI (where performance is one of the main goals) but it could be useful to help the plugin ecosystem transition over.
> Is there space for a native-code main-window on desktop like we have on Android?
Sailfish browser did it as well (using native UI). Desktop Firefox also can benefit from IPCembedlite. But the question will be, what should be used to write the UI. Qt as well?
I'm a bit torn on that, since switching away from "Webby" interface basically killed Fennec for Meego, and only Android started getting UI improvements (that's what triggered a separate browser for Sailfish to begin with).
There are a lot pro`s, who speak for that, front in the row the huge community, the portability, the performance, and the fact that many devs rewrite there existing GUI to Qt, like Musesore, Frescobaldi, Wireshark, Subsurface, VLC, Gcompris, Mkvtoolnix, Dropbox, Megaglest`s Map editor, OpenShot, ufw-frontends, Dolphin-Emu and even two DEs: LXDE and Unity.
Please do that and i am Firefox user for my lifetime. :)
Good thing is servo team is supporting API compatibilty with chromium CEF project. That mean, if you write an html5 app using CEF, it will just work so with servo engine as well.
It would be cool if they took something like NWjs or Electron and made it better. So we could build other apps besides a browser with a cross platform framework.
A few more bits of info from Laura Thompson's presentation, that was mentioned: shipping features can be done even faster if they are done in a modular way, as addons. Firefox supports restartless addons, which means the browser could download an addon and enable it immediately.
Together with work on improving addon APIs (APIs for CSS features were discussed, for example) this could be very interesting.
Here's how I read it... they're looking at ways to move towards rolling release for A/B testing.
Think about it like this, you're using Firefox and you get a notification... "Feature X is ready to test, would you like to try it out? Yes/No" If you select Yes, the feature is rolled out to you and other volunteers immediately (potentially without restarting, depending on the feature), and you can then feedback your experience to Mozilla on how well the new feature works out for you. The feedback from this control group then informs whether Feature X is ready for prime time.
In some ways it seems like it's a restructuring of the Firefox development channels, a mix of beta and stable releases in the same channel.
The model is that we want to make Firefox itself more webby in the way it ships. Features should be independently updatable from the core browser, and we should be able to do phased rollouts to help us watch for issues, control for load, and so on.
We are looking at offering very experimental stuff in a purely opt-in process, and updates to regular features as if they were third party add-ons (with some twists in how they have to be implemented).
It's mentioned only briefly here since the email is mostly about XUL/XBL.
I'm working on the Go Faster project. We hope to deliver a 1-2 features this way by the end of 2015. We have just started on building out needed changes to the client, update service, and build pipeline.
Firefox itself is quite fast [1]; if you're having issues, there's a good chance that it's due to an add-on [2]. A (historically; I'm unsure if this is still the case) particularly egregious offender [3] is AdBlock Plus, but µBlock [4] does come highly recommended.
Hmm...that doesn't sound like normal behavior; my uneducated guess would be that there's a specific webpage or extension with a leak. Next time it happens, it'd be fantastic if you could go to about:memory, save the reports, and file a bug with them attached:
I'll send you a memory consumption snapshot soon.
8 tabs == 1GB memory already but i can live with it for now.
When it eats 3GB+ -- and unfortunately it will - then it'll become an issue.
I'd rather they'd spend more time making their rendering engine e.g. implement the SVG spec properly[0] than fanny about with this, but, y'know, I'm not in change.
Many a time I've said this to people but truth is the number of projects I already contribute to is greater than the time I really have to devote to them.
There are two high-level components which make up Firefox. The first is Gecko, the rendering engine. The second is Firefox, the application itself, which uses Gecko to render Web pages and itself.
Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).
https://en.wikipedia.org/wiki/XUL https://en.wikipedia.org/wiki/XBL
What's going on here is that Mozilla is considering getting rid of XUL and XBL and building Firefox with the same technologies that people use to build Web content.
There are at least three big advantages to doing this:
1. Eliminate the need to support XUL and XBL in Gecko.
2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.
3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.
The only real downside is the amount of work involved.