
The Firefox UI Is Now Built with Web Components - joewalker
https://briangrinstead.com/blog/firefox-webcomponents/
======
wooptoo
XUL was ahead of its time when it was introduced by Netscape/Mozilla many
years ago. It was a capable XML based language used to describe rich graphical
user interfaces. Together with XULRunner this was supposed to be a generic
framework for creating graphical applications. This was long before HTML
became what it is today. Back then people still thought Java would take off on
the desktop. I believe that most Mozilla products such as the Mozilla suite,
Thunderbird and Firefox used this for a very long time.

[https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...](https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul)

~~~
topspin
> Back then people still thought Java would take off on the desktop.

You know, I find myself using a substantial amount of Java desktop software.

I license JetBrains products and earn part of my living using them. DBeaver is
another frequently used tool. I've spent no small amount of time in Minecraft
(the Java implementation.) Java desktop software even pops up in hobbies;
SimSmith is one example.

There are others. Doubtless there will be more in the future. Are we all
_sure_ Java failed on the Desktop? It certainly didn't wipe out the competing
paradigms, but it's still here and still seems to work pretty well for a lot
of people. There aren't any Java web browsers, but then there aren't any C# or
Python web browsers either, so I'm not sure what unit of measure I'd need to
observe the failure of Java desktop software.

And then there's Android......

~~~
jasode
_> , so I'm not sure what unit of measure I'd need to observe the failure of
Java desktop software._

When people say "Java failed on the desktop", it's in relation to the _initial
massive hype_ in 1995 by Sun Microsystems as the "Microsoft evil empire
killer". Microsoft took the desktop threat seriously and quickly reacted in
1996 with a Java-clone called the J++ language -- which resulted in Sun's
lawsuit.

There was a popular Java slogan back then of _" write once, run anywhere"_[1].
In other words, instead of writing desktop apps that specifically target the
Win32 API, you write Java & Java byte code for the Java Virtual Machine.
Instead of writing raw Javascript, code in Java to run as _Java applets_ in
the web browser. This was the same time period as the slogan _" the network is
the computer"_ that Oracle's Larry Ellison was also pushing. Both Sun and
Oracle were trying to minimize Microsoft Windows' dominance with Java.

So yes, even though niche desktop software like JetBrains IDEs running on Java
is a reality today, it is still somewhat of a failure when it's measured
against the 1990s breathless promises.

It turns out that Java was much more successful on the server side. Ebay,
Amazon, Google, etc all run tons of server-side Java. It is ironic that
Javascript as the "toy" language to add a little dynamic interactivity to
webpages _over-achieved_ on the desktop while Java the "serious" language
_under-achieved_ its goals for the desktop.

[1]
[https://en.wikipedia.org/wiki/Write_once,_run_anywhere](https://en.wikipedia.org/wiki/Write_once,_run_anywhere)

~~~
topspin
> Microsoft took the desktop threat seriously and quickly reacted in 1996 with
> a Java-clone called the J++ language -- which resulted in Sun's lawsuit.

I'm fully aware of the history. I was there and watched it unfold at the time.
I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun
is dead. I'm just objectively counting the number of Java desktop programs I
presently use and wondering if this supposed "failure" on the desktop isn't
really just a widespread misconception. The software that I cited isn't riding
the coattails of a 24 year old marketing campaign; they thrive of their own
merit.

~~~
jasode
_> I also don't think it's terribly relevant; 1995 was a quarter century ago._

It's _relevant_ because the context of the conversation was this gp's quote
you responded to: _" Back then people still thought Java would take off on the
desktop."_

The "back then" is referencing XUL circa ~1997. And the _" Java would take
off"_ was the ambitious idea of _most desktop apps being written in Java_ to
weaken the MS Windows ecosystem. Not only was Java hyped to be a Microsoft
killer, it was also touted to be a C/C++ killer. (E.g. the idea was that
computer desktops have gotten so powerful with so many wasted cpu cycles that
manual memory of C/C++ is obsolete and letting GC use the excess cpu to
automatically manage memory is the future.) History has now shown us that
prediction didn't happen either. C/C++ is still heavily used for new desktop
apps. That's a different idea than today's 2019 landscape with some niche Java
apps like Jetbrains IDEs.

I do understand your point. Yes, you can _also_ have an alternative definition
of "not a failure on desktop " because you can count some current Java apps
_today_. That's also a valid perspective. However, for the sake of not
confusing the conversation... that's not what the gp was originally talking
about. I don't think there's any misconception about what "Java failed on the
desktop" means -- especially among the HN audience. I also regularly use
Jetbrains IDEA for Android deveopment and Webstorm for Javascript but my usage
of those Java apps doesn't change what "Java failed on the desktop" means to
other people.

~~~
topspin
Yes, I moved the goal posts making my point. I believe the storied history of
Java clouds the contemporary reality of Java too much, to the point where one
can argue Java "failed on the desktop" specifically among people that spend a
good fraction of their waking hours using Java desktop software, and I appear
to be one of the few that notices this irony.

------
Hamuko
I'm waiting for Firefox to start using a native context menu on macOS instead
of the garbage that they are now using and which doesn't behave anything like
any other context menu on macOS.

It's luckily on Bugzilla, so I can keep monitoring progress daily.

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

~~~
tzs
There are a couple of other non-native things Firefox does that annoy me.

1\. It has its own certificate system. That would be fine if it used that in
addition to using the MacOS built in system, but it seems to use it
exclusively.

2\. It has its own spell checker, which is orders of magnitude worse than the
one provided by the native MacOS spell check API. I can't think of any program
I've used in the last few years on Mac or Windows that had a worse spell
checker.

LibreOffice is open source and its spell checker is fine as far as I've seen--
definitely way better than the one in Firefox--so that if Mozilla for some
reason needs to have the same spell check on each OS and so can't use the
native MacOS one, they could still bring it up to par by copying from
LibreOffice.

~~~
Groxx
_> 1\. It has its own certificate system. That would be fine if it used that
in addition to using the MacOS built in system, but it seems to use it
exclusively._

fwiw Chrome does this too. It's effectively standard practice for browsers -
OSes routinely have very out-of-date cert stores, and don't regularly remove
revoked ones. Browsers ship it separately because it's such a major security
concern for browsing.

~~~
tzs
Chrome on MacOS does use the Mac's built-in system. Going to the privacy
settings (chrome://settings/privacy), and clicking "Manage certificates" just
launches the MacOS "Keychain Access" application.

To get Chrome on MacOS to use my employer's self-signed root certificate, I
just had to import it with "Keychain Access" and then both Chrome and Safari
used it.

It may also have its own built-in certificate system, but for user-added
certificates, it uses the built in MacOS system.

------
jhatax
Here’s my XUL development story:

I built and managed (2009-2011) the XUL-based Elasticfox extension for Firefox
that allowed users of EC2 to manage their compute resources on AWS. The
extension pre-dated the AWS Console and introduced features such as resource
tagging and search before they were part of the SDK.

The extension wouldn’t have been possible without XUL. In fact, it isn’t
possible today. MDN documentation was really great even in those days, as was
the community which answered a number of my questions. I was doing something
really new, especially with calling into EC2 APIs, background refreshes, using
Prefs.js to save tag information, etc., and the community was really
responsive and supportive of my work. Quirks aside, my experience with XUL was
great. Users truly appreciated the extension over the Java-based CLI, and a
number of ideas (mine or those from the community) eventually made their way
into the AWS Console.

I spent my last year at AWS working on the S3 Console using web technologies.
I found XUL development to be easier than hacking CSS that year (circa
2010-11).

Edit: Added a note up top that this is my XUL story.

------
ajxs
Isn't this the kind of thing we've been looking to move away from? I
personally think that this modern trend of implementing, or even worse
-porting-, important functionality in Javascript is very worrying. There was
another recent controversial discussion of Electron on HN where I and many
others shared our reservations about badly Electron apps perform overall.
They're disproportionately resource intensive, shred battery life, hog
resources etc. I don't think that deprecating XUL is a bad thing, but is
moving to another JS based solution _really_ a good idea? I've been a
supporter of Firefox for a long time and intend to continue to do so. I tend
to favor lightweight programs and while I want to continue to give FF my
support, I'm concerned with how bloated and slow it's becoming.

~~~
sixplusone
Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers
are the "Lowest Common Denominator" for cross-platform apps.

~~~
buboard
There are a ton of cross-platform GUI libraries

~~~
weberc2
As someone who loves the idea of a good cross platform GUI, there simply
aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but
manageable. You get to work in a bastardized dialect of C++ (that no editors
understand save Qt Creator) or use a leaky Python binding (that still
segfaults), but you can build things that don’t look awful. As far as I know,
this is the only cross platform GUI tool for which this can be said (except
for the browser-based solutions, of course).

~~~
jcelerier
> You get to work in a bastardized dialect of C++ (that no editors understand
> save Qt Creator)

Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just
plain preprocessor macros which resolve to nothing
([https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...](https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qobjectdefs.h?h=v5.8.0#n93)).
If your editor does not support resolving empty macros it does not support C++
at all anyways.

~~~
weberc2
This misses my point. If I create a language and assign different semantics to
the Python AST, an editor that supports Python does not meaningfully support
my language. The syntax highlighting will work, but any semantic analysis will
break.

That's what you get with Qt absent the moc (meta object compiler).

Moreover, there is still a host of reasons why Qt is a painful developer
experience (even though it is probably the best cross platform _native_
option). For example, even if you solve the editor problem, you can't
_reliably_ use C++ templates, and Qt has its own strings, lists, hashmaps,
concurrency mechanisms, memory model, etc. And even if it were _just_ C++, C++
itself is a pretty poor experience compared to other languages on the market
these days.

So Qt might be the best thing on the market today, but it's not hard to
imagine much better alternatives. For example, browser support for native
system things that would render electron obsolete (especially as WASM matures)
or perhaps Flutter as its desktop story matures. Or maybe even a mature
intermediate GUI toolkit in a modern language.

~~~
jcelerier
> This misses my point. If I create a language and assign different semantics
> to the Python AST,

but which semantic differences are you talking about ? It is plain C++.
Function calls are function calls, the only difference being that some are
auto-generated and some are your own code.

~~~
weberc2
C++ has no notion of signals and slots or other metaobject utilities. Your
editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I
encourage you to not get too hung up on this particular issue with Qt and
consequently miss the broader point.

~~~
jcelerier
> Your editor cannot autocomplete those signals/slots like Qt Creator.

what do you mean ? signals and slots are just plain functions, there is no
magic to understand ; the only thing that QtCreator does is to display a
different icon in the autocompletion toolbox.

Do you have an example of an IDE that is not able to autocomplete a signal ?
VS is able to, vscode is able to, Xcode is able to, code::blocks is able to,
hell even notepad++ in all its "non-intelligence" manages to.

> Anyway, I encourage you to not get too hung up on this particular issue with
> Qt and consequently miss the broader point.

I am saying that this point does not make sense - else every library which has
some concept not perfectly transmitted by raw C++ code (for instance : a
library function whose correct execution / lack of UB depends on the
programmer calling another function before that) would be problematic.

~~~
weberc2
Signals and slots _compile into_ plain C++ functions. The input language (the
unnamed Qt superset of C++) has a notion of signals and slots, the output
language (C++) does not have any such notion.

> I am saying that this point does not make sense - else every library which
> has some concept not perfectly transmitted by raw C++ code (for instance : a
> library function whose correct execution / lack of UB depends on the
> programmer calling another function before that) would be problematic.

My point does make sense, you're just missing it.

First of all, my point is that Qt is a poor developer experience--that its
interface is bastardized is merely evidence. Further, even if it were not
bastardized, it would still be awful _because it 's C++_ (insane build
tooling, no package management, poor error messaging, no memory safety,
enormous feature matrix, etc etc etc; all of this has been covered elsewhere
ad nauseum, no need to repeat those arguments here). There's a long tail of
additional issues with Qt that contribute to its unpleasantness, but there's
no point in diving into them here.

Secondly, your stateful library functions example doesn't fit my criticism
because stateful functions are part of the C++ language spec while signals and
slots are not.

~~~
jcelerier
> Signals and slots compile into plain C++ functions. The input language (the
> unnamed Qt superset of C++) has a notion of signals and slots, the output
> language (C++) does not have any such notion.

If that was the case, gcc and clang would not be able to build Qt files. Yet
the following compiles without issues :

    
    
        echo "#include <QObject>\nstruct foo : QObject { signals: void bar(); public slots: void blah() { } };" | g++ -std=c++11 -fPIC -I /usr/include/qt/QtCore -c -x c++ -
    

which is _all_ that is needed to ensure that some code is indeed 100% valid
C++ code - that it is idiomatic is a wholly different question.

hell, you can even generate the signals code without moc if you are ok with
more macros
([https://github.com/woboq/verdigris](https://github.com/woboq/verdigris))

~~~
weberc2
No, it just means that Qt is valid C++, not that the two have equivalent
semantics (which is necessary for Qt to be exactly C++ and not a bastardized
version thereof, which is what we are debating). If I we’re wrong and you were
right, the moc would be purely optional; it would serve no purpose, and Qt
programs compiled with moc would behave exactly as those compiled without.

------
bryanh
Just peeking through the tracker history
[https://bugzilla.mozilla.org/show_bug.cgi?id=1397874](https://bugzilla.mozilla.org/show_bug.cgi?id=1397874)
and you can see the effort it took to land this magnitude of a change --
pretty astounding. Big hat tip to Brian and the FF crew!

------
matheist
I built a userChrome.js replacement [+] back when FF 57 came around, that uses
an XBL loophole to permit users to add custom javascript to their profiles
that would run in the browser context. I wanted to be able to use pre-OS X
Lion fullscreen mode, and couldn't find any other way to do it.

I'm a little bummed that this loophole is going away in FF 72 (I still can't
get pre-Lion fullscreen!). On the other hand, it has always been super clear
that this is a loophole that will eventually go away, and I did get 2 years of
use out of it, so I'm not complaining too loudly. Congrats to the team for
removing XBL!

[+] [https://github.com/nuchi/firefox-quantum-
userchromejs](https://github.com/nuchi/firefox-quantum-userchromejs)

~~~
girvo
It’s been so long that I genuinely can’t remember what that full screen mode
looked like! Do you have a screenshot by any chance?

~~~
matheist
The content stretches all the way to the top of the screen. No menu bar, no
tab bar, no toolbars.

~~~
abyssin
This is the only feature I miss from Chrome on OSX.

------
pfraze
Incidentally, so is Beaker browser's. We use lit-elements, which I like a lot.

~~~
hunterloftis
I've also been enormously impressed with the design of lit-element, which
carefully balances ease with simplicity.

Just enough abstraction to automate the hard stuff without dictating your
architecture.

------
sho
> There was also a case where a user with over 1500 tabs open (scientifically
> considered a “tab hoarder”) noticed extreme slowness when opening the “all
> tabs” dropdown. It turned out that he had tripped on an O(N²) edge case, and
> the issue was fixed.

Good god.I've seen some ridiculous tab collections but that is next level.

~~~
afiori
I essentially use tabs as dynamic bookmarks; as a stack almost.

I never use multiple windows in any browser because they are unreliable with
tab reloading.

------
BoumTAC
can it cause perfomance issue ?

I know for example the devtool is written in react and it's a lot slower than
chrome devtools (I don't know how chrome devtool is written) and the
javascript debugger is sometime not even usable because it's so slow.

~~~
jasonlaster11
Hi, Firefox DevTools Debugger engineer here.

We've focused on performance and quality over the past six months and believe
it should be much better.

If you're still seeing issues, feel free to record a performance profile and
send it to us:

\- [https://profiler.firefox.com/](https://profiler.firefox.com/) \-
[https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&...](https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&component=Debugger)

I'd be happy to fix it!

~~~
the8472
I find it mildly amusing that there's a profiler in the devtools. And yet
there is another profiler that is at times more powerful than it. I have used
the gecko profiler from time to time to identify which feature the page was
using that slowed down the entire browser. Multi-process means just debugging
a single tab doesn't give you the whole picture.

------
ravenstine
Poor web components. Everybody rags on them.

~~~
ng12
Because the API is really ugly. I can't see them ever taking off except maybe
as an implementation of another library with a cleaner API.

~~~
cmpolis
This is one of the goals of Polymer- a cleaner API/abstraction layer on top of
web components, right?

~~~
floatboth
Well, forget about "Polymer the library", it served us well but it's very
legacy at this point. The successor is [https://lit-element.polymer-
project.org](https://lit-element.polymer-project.org) and it's _awesome_.

~~~
interlocutor
Why on earth do you need something that heavy? How about this 200-line lib
instead:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)
It lets you TSX format (same to React) to implement as well as to use web
components.

~~~
spankalee
> Unlike React.js UIBuilder does not do incremental screen updates

LitElement + lit-html give you very efficient updates, and don't require non-
standard JS like JSX.

~~~
interlocutor
lit-html is no more of a standard than JSX. In fact JSX is better because
tools like VSCode is able to validate both HTML _and_ embedded JavaScript.

~~~
spankalee
Huh? lit-html uses standard JavaScript. That's it. JSX is a non-standard
extension. So yes it is more standard than a non-standard, and lit-html runs
directly in browsers without any transpilation while JSX very much doesn't.

VS Code is as able to analyze lit-html templates as well as JSX via the lit-
plugin extensions. It gives you type-checking, code completion, hover-over
docs, and linting.

~~~
interlocutor
lit-html needs a 1600 line library where as UIBuilder is a 200-line library:
[https://github.com/wisercoder/uibuilder/blob/master/UIBuilde...](https://github.com/wisercoder/uibuilder/blob/master/UIBuilder/UIBuilder.ts)

Yes, JSX needs transpilation but that happens at compile-time. Which is
better, pre-processing at compile-time, or "transpilation" (i.e., string
processing) at run-time?

~~~
spankalee
UIBuilder doesn't do incremental updates at all. You might as well use
innerHTML and template literals. That's a 0-line library :)

~~~
interlocutor
Updates offered by lit-html appear to be very limited. If you change value of
expressions it updates the DOM. What about larger changes, such as list items
changing? What about child elements being replaced with new ones?

~~~
spankalee
It handles all of that.

~~~
interlocutor
That does not appear to be correct.

[https://github.com/Polymer/lit-html/wiki/How-it-
Works#4-upda...](https://github.com/Polymer/lit-html/wiki/How-it-
Works#4-update)

Excerpt:

 _update() simply iterates through each part and value (the parts array and
values array are always the same length) and calls part.setvalue(v) for each
part._

[https://lit-html.polymer-project.org/guide](https://lit-html.polymer-
project.org/guide)

Excerpt:

 _Behind the scenes lit-html creates HTML <template> elements from your
JavaScript templates and processes them so that it knows exactly where to
insert and update the values from expressions._

This is very limited. You need to manually update DOM unless your updates are
simple changes in values of expressions.

~~~
spankalee
It is very correct: lit-html is amongst the fastest template systems in use
right now. This is shown in every benchmark I've seen or made for it.

lit-html updates only the parts of DOM that are dynamic and change. It handles
nested templates as values, only updating the whole nested template if the
template itself changes, otherwise recursing and only updating that template's
values if needed. Repeated DOM is handled either by simply updating state for
each item in sequence (non-keyed), or by using the repeat() directive which
will move DOM (keyed).

You absolutely don't need to manually update DOM. The whole point is to
describe your DOM structure as a function of data, and to be to describe all
the conditional / repeated parts in the template expression itself.

------
mosburger
I wrote an open-source cross platform app entirely in XUL + Javascript once
and it was an awful experience - incredibly hard to debug and get all the
bindings working right. Congrats to the Mozilla team on what has to be a very
satisfying improvement!

------
etse
I don't know if the move to web components somehow resulted in superior font
rendering for Firefox on Mac, but I just checked version 71.0b11 and it looks
great – at least as good as Safari.

I just couldn't stand the blurry text, so now I'll give it a go and switch
back to Firefox. Although, the colors look far more saturated than they should
be, like the orange Hacker News navigation bar.

------
johnpowell
I read the blog post and wasn't able to figure out if this would break
userChrome.css.

I'm not that weird about change and normally accept it and end up not caring.
But I have tried to get used to tabs on top and it just isn't happening. If I
can no longer have that I guess I will need to get used to Safari. Or I will
just keep using Firefox and not update and accept the security implications.

~~~
severine
I use Firefox Nightly and a couple of the latest updates broke my
userChrome.css. On the other jand, it took me just minutes to fix, by asking
in r/FirefoxCSS, where there are some kind and helpful CSS ninjas.

Link:
[https://www.reddit.com/r/FirefoxCSS/](https://www.reddit.com/r/FirefoxCSS/)

------
BlackLotus89
Does this mean the missing extension icons I got for a few days now are
because of this? (I use nightly) or is this an uncorrelated bug and I now
think that the rewrite is at fault because I combine unrelated information?

~~~
konart
I don't think it's related. They were removing XBL piece by piece for a quite
some time now. /r/firefox has many mosts about such removals.

Anyway - nightly is a dev build. It is expected to have bugs of all kinds.

------
agumonkey
Reminds me of the firefox.html protothingie someone showed a few years ago.

~~~
sp332
Browser.html, a Servo demo.
[https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

~~~
paulrouget
Looked like this: [http://paulrouget.com/bhtml/](http://paulrouget.com/bhtml/)
but the project died.

------
axilmar
Was there a reason for XUL in the first place? Why wasn't Firefox built using
some GUI library? I've read what the posted page said, and the comments in
here, and the first results from Google don't give any reason why XUL was
necessary.

To me it seems many hundreds, if not thousand, man years spent on something
totally unnecessary.

------
zem
that sounds like a massively satisfying project to be involved with!

------
dudidu
This is awesome!

------
kick
Remember when a tab freezing didn't make Firefox's UI chrome unresponsive? I
do, too.

~~~
pessimizer
Web 4.0 is the internet of race conditions. Thanks, javascript everywhere.

~~~
hombre_fatal
I don't get it. Javascript would have categorically improved on this compared
to more traditional multi-threaded solutions.

~~~
GrayShade
You can still have race conditions in single-threaded async code.

~~~
cjones26
Well I don't think that could technically be considered a race condition, as
it's clearly a design problem in the code causing what would appear to be a
"pseudo" race condition.

~~~
GrayShade
Why not? It is a race condition, just like TOCTTOU is a race condition that
doesn't necessarily involve threads.

Note the difference between race conditions in general and data races that
involve unsynchronized access to shared memory.

------
lloydatkinson
That’s great and all but I’m still waiting on a spell checker. How can this
still not be a thing?

------
amelius
Security implications?

Does this strip away a layer of security?

~~~
mcpherrinm
Firefox used to be built in a custom markup language called XUL, which had a
number of security issues over the years as it got less attention than the
HTML, etc used to render page contents.

So this should help Firefox be more secure, by decreasing attack surface.

~~~
noja
But XUL was simpler, wasn't it?

~~~
pcwalton
Maybe marginally so in isolation? But that isn't the metric that matters,
since a browser has to render HTML. HTML + XUL is more complex than just HTML.

------
musicale
And the FireFox UI still sucks. It's ugly and clunky. The look and feel is
just off, and it isn't responsive.

One of the reasons I prefer Safari on macOS is that it actually has a native
Cocoa UI.

~~~
cerberusss
Yes, the Safari UI basically defines the look and feel for macOS. However
Firefox has some advantages in other areas, like ad blocking.

~~~
musicale
Yeah, I appreciate Apple's attempts to sandbox content blockers for security
and privacy reasons, but I still miss ublock origin.

------
breatheoften
Wow - that must be an incredibly messy UI codebase by now ...

~~~
ergo14
You know, chrome UI is also web components in many places.

~~~
mosselman
Do you mean that it is OK to have messy code as long as your competitors do
too or do you mean that since chrome is doing it, it can't result in messy
code?

~~~
ergo14
I see no connection between WC's and messy code. Can bo good, can be bad.

~~~
breatheoften
Just saying -- transitioning a large project from one component system to
another -- while also developing/evolving the new component system ...

I can just imagine it would be easy to build up a very large mess ...

------
tomc1985
Everyone celebrates this, as if it were something worth celebrating. Yet all I
see is another stake through the heart of desktop and native UI.

~~~
spankalee
You don't think XBL was more native than HTML do you?

~~~
tomc1985
It was. It rendered to GTK which renders to native widgetry

~~~
paulrouget
Not more native than HTML.

~~~
tomc1985
Sure, when people didn't style buttons or text boxes, because those also used
native widgets

------
FpUser
Bah, I was wondering why it suddenly feels less snappy. Generally I am against
Electron and other web based UI layers. However since browser must have built
in web GUI framework by definition it does make mush sense from the
architectural and business standpoint to use the same thing for browser own
GUI as well.

~~~
gnomewascool
> Bah, I was wondering why it suddenly feels less snappy.

Were you using Nightly?

If not, then it's most probably unrelated.

------
potiuper
'There was also a case where a user with over 1500 tabs open (scientifically
considered a “tab hoarder”)' \- by what metric?

~~~
chc
By number of tabs open, it sounds like.

~~~
potiuper
To be a hoarder, one would need to accumulate the hoard over a period of time,
which "the number of tabs open" is not a measure of. Also, as stated in the
article, an issue with a large number of tabs was found, yet it was not
declared that the tester(s) were also hoarders by the metric of the "number of
tabs open".

------
dependenttypes
People seem to love laggy web-sights, let's port the lag into the browser's
UI!

~~~
mintplant
Firefox has _always_ been built with DOM, JS, CSS technologies, as the linked
article calls out. This change replaces a large proprietary extension, XBL,
with a standard equivalent.

~~~
dependenttypes
Calling XBL a proprietary is weird when considering that it is published by
w3c and that firefox is FOSS.

> Firefox has always been built with DOM, JS, CSS technologies, as the linked
> article calls out

I am aware of that (and imo, it was a mistake). That however does not mean
that moving to more web-y stuff will not make the performance any worse.

~~~
2ion
The language is official.

[https://mozilla.github.io/firefox-browser-
architecture/text/...](https://mozilla.github.io/firefox-browser-
architecture/text/0005-problems-with-xbl.html) says:

> XBL is a proprietary technology developed by Mozilla. We are solely
> responsible for the maintenance and improvement of XBL. Any time spent on
> doing this doesn’t contribute to the evolution of the Web so effectively we
> don’t spend anytime improving XBL except for plugging serious holes.

What they mean is they 'own' it, the good, the tedious and the bad parts.

