
Revisiting how we build Firefox - clarkbw
https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html
======
joshmoz
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).

[https://en.wikipedia.org/wiki/XUL](https://en.wikipedia.org/wiki/XUL)
[https://en.wikipedia.org/wiki/XBL](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.

~~~
piyush_soni
The only thing I'm worried about is how would it affect performance. Does it
mean the UI itself would be rendered using Gecko Engine?

~~~
campd
Like pcwalton said, we already use Gecko to render the UI. But we're using a
less well-optimized, less well-maintained corner of Gecko.

Improving performance is an explicit goal of this work.

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

~~~
frozenport
A lot of people agreed with you and built Camino and K-Meleon.

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

~~~
frozenport
Here is a difference of opinion:

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.

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

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

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

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

~~~
pcwalton
In a sense, Chrome has been moving further and further away from being native
over time; in-content preferences, for example.

------
JoshTriplett
Mozilla has been doing experiments in building browser UI in HTML for a long
time. For instance, see Chromeless (
[https://blog.mozilla.org/labs/2010/10/chromeless-build-
your-...](https://blog.mozilla.org/labs/2010/10/chromeless-build-your-own-
browser-ui-using-html-css-js/) ).

Current HTML is capable enough. It's nice to see them talking about adopting
that in mainline Firefox.

~~~
agumonkey
Accidental downvote. I thought it was
[https://github.com/mozilla/browser.html](https://github.com/mozilla/browser.html)
, I never heard of this chromeless effort.

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

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

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

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

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

------
abhv
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?

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

------
shmerl
_> 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).

~~~
gcp
Meego dying killed Fennec. It would have gotten further development if it had
had users that warranted so.

~~~
shmerl
Meego became Mer on which Sailfish is based, and it has enough users, so your
argument is invalid.

------
ShalokShalom
Please please please :D

Use this chance and port Firefox to Qt:

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

------
drapper
That reminds me of what Vivaldi is trying to do
([https://vivaldi.com/](https://vivaldi.com/))

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

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

------
therealmarv
Keep XUL, XBL. Mark it deprecated. Make plugin development as easy as in
Chrome for the new API. Would be awesome and so appreciated!

------
madez
Does this imply that It wouldn't possible anymore to use Firefox to browse
without Javascript?

~~~
gcp
Firefox already uses a ton of JavaScript internally. The setting for web
content has nothing to do with the internals of the browser.

------
rockdoe
The faster deployment thing seems pretty vague and free of actual content.

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

~~~
kazagistar
If this means that I could easily uninstall all the bits of firefox I don't
use, like bookmarks, that would be pretty cool.

------
gesman
Please keep these little icons unchanged, i don't care about it.

Do not make tabs cuter, I don't care about it.

But PLEASE - do something to stop Firefox from being such a bloated memory hog
- I deeply care about it.

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

[1] [http://arewefastyet.com](http://arewefastyet.com)

[2] [https://support.mozilla.org/en-US/kb/firefox-uses-too-
much-m...](https://support.mozilla.org/en-US/kb/firefox-uses-too-much-memory-
ram#w_disabling-memory-consuming-extensions-and-themes)

[3] [https://blog.mozilla.org/nnethercote/2014/05/14/adblock-
plus...](https://blog.mozilla.org/nnethercote/2014/05/14/adblock-pluss-effect-
on-firefoxs-memory-usage/)

[4] [https://addons.mozilla.org/en-
us/firefox/addon/ublock/](https://addons.mozilla.org/en-
us/firefox/addon/ublock/)

~~~
gesman
I didn't say it slow. It is indeed fast. Thank you for that!

Until suddenly the show stops and I have to kill it via Taskmgr to inject new
life into it due to memory suffocation.

~~~
chuckharmston
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:

[https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox](https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox)

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

[0]
[https://bugzilla.mozilla.org/show_bug.cgi?id=437554](https://bugzilla.mozilla.org/show_bug.cgi?id=437554)

~~~
maccard
Feel free to contribute, FF is an open source project driven by people like
you who get annoyed at bugs like this.

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

