Hacker News Reader

> 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

Try https://web.archive.org/web/20151126183335/https://www.jwz.o... if the link doesn't work...

Killing XUL has the potential of killing Firefox. I bet the last good XUL version will be forked.

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.

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.

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.

As an active user of Thunderbird I am very disappointed with these news.

But these rants are just silly. XUL is a technology that needlessly duplicates what HTML/CSS do these days. And if you ever want to have a smooth transition to servo, which solves real, deep problems, having a html UI is going to be dramatically important.

I really want to agree with you that Atom is awesome, and it is, in principle, but in reality a text editor should not be using 300MB of RAM. Sublime Text, which I consider to be a direct competitor, barely uses 20MB of memory on my machine even after hours of use. Heck, does Intellij even use that much memory?

I'm just really discouraged with how more and more desktop apps are being written in HTML, CSS and Javascript and suffer in quality as a result.

IntelliJ has something between 100mb and 700mb depending how much projects you have open and what language you use.

Considering my first 16 Bit computer had 3MB RAM and ran MS Word alongside a GUI, I am wary to say "Amount X of RAM is preposterous for a given task".

As long as Moore's law provides enough lift under our wings, RAM usage is one of the less important aspects of an application. However, I fear the trend of building application UI's in HTML/CSS because invariably it will lead to wildly inconsistent look, feel and behavior.

Reminds me of the quip that goes something like this: "What's the best way to save 10 dollars? Earn 10 dollars more."

Eight Megabytes And Constantly Swapping used to be a joke.

Sigh. I feel old.

It's worth pointing out that for a couple of years Mozilla has been building a replacement for their rendering engine (Servo), so I imagine that to some extent deprecating XUL now is preparation for not having to re-implement it for Servo. Just speculation.

> One might say that Mozilla will wait to release the new Firefox till it has all the old features of the old Firefox, but that's not been my experience with how teams work.

Realistically, getting to feature parity after rewriting a core part of any application is going to be nearly impossible. You end up with different features, hopefully better ones, but not exactly the ones you had before you started. You can't step twice in the same river.