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
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.