Hacker News new | ask | show | jobs
by simpleigh 3859 days ago
> The reasons given, that XUL requires maintenance that Mozilla engineers don't enjoy doing, is a joke considering the amount of effort to maintain XUL is less than 1% of the amount of effort to move Firefox to HTML.

Ah, but maintaining XUL means working on old code (which is boring), but moving Firefox to HTML means working on new shiny code (which is exciting).

https://www.jwz.org/doc/cadt.html

4 comments

Well, or Firefox as a web browser has to render HTML/CSS/JavaScript no matter what, and now that HTML/CSS is at feature parity or better with XUL in the space XUL is meant to occupy, it doesn't make sense for Mozilla to maintain two competing technologies when one receives 95% of their internal developer attention and 99.99999999999999% of external developer attention.
But, sadly, they aren’t replacing XUL with HTML.

Instead, they plan to render the UI natively, with only "some" parts in HTML.

So, instead of XUL + HTML, we’re going to get GTK + WinForms + Cocoa + HTML. Great, eh?

And we lose the ability to style it with addons – your themes can only change the background image of the header bar, that’s it.

And the remaining addons can’t modify the UI (tree style tabs, bottom tabs, etc) anymore either, instead you can only modify page content.

I’m seriously pissed off now, because Firefox was the last browser where I could actually customize it how I liked it.

I hope the person who made this decision is going to have to use software without any config options and with horrible defaults, like GNOME. For the rest of their life. May their car always have have either 60°C+ heat, or -20°C AC, may their screen of their phone always either be too dark, or too bright.

Yes the plan is to replace XUL with HTML. I have no idea where you heard otherwise.
> Part of the decision has already been made. We are moving Firefox addons (themes and extensions) away from a model where you can perform arbitrary styling or scripting of the browser chrome. This is an engineering-driven decision, and it's unavoidable and necessary for the long-term health of Firefox. Not only are we moving Firefox away from XUL, but we are likely going to make significant changes in the way the UI is structured. It is likely that some parts of the UI will be implemented using native widgets, and other parts will be implemented in HTML, but the exactly DOM structure may involve independent connected with well-defined API surfaces.

Official statement from the Mozilla post in the discussion regarding removal of support for "heavyweight" themes. Emphasis mine.

That’s a pretty clear statement that it won’t be 100% HTML.

Also, the fact that "arbitrary styling and scripting" won’t be possible is another issue.

Tell me how I am supposed to write an addon that adds tab-previews as thumbnails when you hover over a tab like Vivaldi is doing it: http://i.imgur.com/vqysJs1.png ?

How am I supposed to write an addon that colors the navbar and the current tab in the theme color given by the HTML, or, if not existing, the favicon?

With current addons I can do that, with the new addon system, I’m seriously fucked.

You're citing jwz's CADT post in a thread discussing Firefox? It's a product for which people regularly complain about open bugs that are 10 or more years old.
Killing XUL has the potential of killing Firefox. I bet the last good XUL version will be forked.
It essentially already has http://www.palemoon.org/

The Palemoon developers understand the folly of ditching the flexibility of the XUL interface. They won't be removing it.

And then the person who forked it gets to maintain it!

Lucky them.

No need to be so snarky, he'll have all those other people out there who love XUL to help him.
He's right. Mozilla, a $200-300 million a year outfit, currently maintains their software including Firefox. It's a huge C++ application. People who code XUL in their spare time, even a bunch of them, aren't likely to make a dent in keeping parity between a Firefox fork and the main release. They'd likely have trouble even porting it.

So, a fork is a rough solution and will have maintenance issues for an app this size.

I was being facetious.
Ah. You got me there haha.