When Firefox loses the extensions which require XUL (whether fundamentally or merely to avoid rewrites) I doubt its upsides will outweigh its downsides for me anymore. They may surprise me, and even if they don't they still might increase usage with other people, but right now I am sad.
This is its biggest upside and I suspect that I'm not the only one who sticks to FF pretty much exclusively because of it. I am even willing to look past their shenanigans with Pocket, EME, Loop, featured tiles and all other "for the sake of our users" crap Mozilla keep on stuffing into the browser. One thing is pretty obvious though - Mozilla now don't really give a damn about "community". They do what they want to do and the only deterrent is a risk of lash back from said community, rather than their approval.
Like what? Genuinely curious.
Being able to just type in the random things you remember from a url / title (I think it combines them) and have FF narrow down the alternatives, -fast, is something I haven't found in any other mainstream browser.
Another aspect is it doesn't automatically send everything you type to google (I don't worry to much but it is a nice touch.) Maybe the average user is confused by having a separate search field in addition to the address bar but I like it. (And yes, you can search from awesomebar as well, although there is no suggest feature.)
1. Tree Tabs: this extension lays out my tabs stacked vertically on the left of my window. I can fit upwards of 50 tabs in a window before I have to scroll the tab list. This is great for managing big research or documentation sessions without the squinting in Chrome. The APIs necessary for tree tabs are not yet in chrome, although there is some discussion now of a sidebar API.
2. Vimperator: this extension provides a very powerful vim-like interface, including a .vimperatorrc file. I don't use any more of the advanced features like that, but it is excellent for keeping my hands totally on the keyboard as I switch between Tmux splits, vim windows, and my browser. There are several vimperator-inspired plugins for chrome, some of which are passable. However, vimperator is a lot faster than Vimium, and the interface is more concise and vim-like. A big difference is the UI for opening links: in Vimperator, you press `f` to enter follow-link command mode. Each link is assigned a number by page order; you filter links by typing letters, and can follow the first link by pressing `enter`. So to submit this text form, I would press `esc` to return to normal mode from edit mode, then press `f`, and then type "rep<enter>" to filter links to reply, and then click it. It's rather natural, and easy to click the right link.
In Vimium, each link is assigned two letters (which are easier to type than numvers), but you can't filter links. There's a lot more squinting at the little labels to type the right thing. Plus, it's easy to fat finger the link text with no recourse.
1. Tab Groups: This is a must have for organizing tabs and keep me sane with 30+ tabs open. 2. Lazy loading: I am not sure if Chrome has it or not but FF doesn't load a tab content until I switch to it. I can regularly have a lot of tabs open without all of them using resources.
Circumstantial: In most cases I prefer the way Firefox handles runaway scripts. Though when it fails, it fails hard.
There are many others, though like I said...I doubt they'll out weigh Chrome's advantages sans the existing extension ecosystem.
Looks like they realised that to keep moving forward, clean up technical debt and fix longstanding issues, they'd unfortunately break almost all extensions in the process. And if that's the case, they might as well switch to a better API while they're at it. It's painful, yes, but Firefox is still a slow, unstable and memory-guzzling behemoth, where all your extensions break on every update. This won't change if they stick with single-process, XUL, XPCOM and the existing extension model.
I am optimistic. I think Firefox can and will survive this. Look how well Apple's Mac OS to OS X transition went. Mozilla are willing to help people port extensions. And their timeline is probably unrealistic, but it can be pushed back. In two or three years, Firefox will be a world-class browser again, and we will look back at the panic we had now and laugh.
Using dozens of extensions, this has not been my experience or the experience of many others I know. I believe the problems with extensions breaking and memory consumption were solved years ago; AFAIK tests show Firefox' memory consumption is less than Chrome's (in part because of the single-process model) and performance, at least a little while ago, was slighlty better. I haven't experienced, seen, or read about instability.
I don't think it's to do with extensions, though. I'm saying XUL, XPCOM and the single-process model hurt Firefox's maintainability and performance.
I was hoping Servo would be their flagship in 3 years :/
It's strange that XUL survives for so long. Adding an additional markup language to CSS, JS and HTML/DOM to be used for extension development has been bold. For some time, they would have had the chance to push XUL for general development (when Qt and WPF/XAML were not yet that much more modern).
Of course, it didn't catch on, so Firefox was stuck with an obscure UI language only it used.
I guess it's good that they acknowledge that they didn't get input from those that write extensions before they made this decision.
I am a bit cranky over the entire thing, while I can understand the devs think this will be cleaner code, it sounds like a lot of time spent on working on things to get back to the status quo.
From the article: "It sounds like you've made decisions without community input, why?"
"We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution."
Let's break this apart a bit. They think its a necessity, so they did not ask others? I don't think this is anything but ignoring the question.
They then go on to ask for help so that they can spend a bunch of time to return us to a status quo with less working extensions today, and continue to say that you should postpone development for a Firefox extension if you are thinking about working on one, "for a few months." Might as well start targeting Chrome since you cant even rely on FF to have a reliable API to even build a new extension against for a year.
Not to mention all the time and energy spent learning XUL's magical inner workings all gone to rot.
I guess there must be some HUGE technical impetus for this, because from my personal user perspective it seems mind bogglingly wasteful of time and resources.
If not I'll keep using the last version with proper extension support for a long time, until an alternative comes.
Roughly what he said might be summarized as follows (sorry if I misunderstood his intention): Tree Style Tab is useful because the add-on changes the behaviors of the tab globally. That way, it can cooperate with other tab-related add-ons whose authors didn't intend to make the add-ons work with TST. Therefore providing the Sidebar API doesn't help because you can't expect add-on authors to write code just to make add-ons work better with TST.
[1]: https://twitter.com/piro_or/status/635078508981555202 https://twitter.com/piro_or/status/635079271032090624 https://twitter.com/piro_or/status/635079995371556864
At this moment in time, Firefox relies on XUL for both the Firefox UI and its extensions. Mozilla wants to move away from using XUL. What's the sensible approach for this?
In my opinion they're doing exactly what they should.
Step 1. Offer new extension APIs that are compatible with other browsers and decpreciate XUL.
Step 2. Encourage existing XUL-based extensions to be rewritten using the new APIs.
Step 3. After the majority of well used extensions use the new APIs, rework Firefox to drop XUL and use web technologies for the UI.
Step 4 (Not confirmed, but could happen). After the new Firefox UI is stable, offer lower level APIs to give further control over the UI.
I can't see a better way of moving away from XUL.
https://github.com/mozilla/browser.html
In the short run, perhaps try an ESR release?
This will mean my extensions for all three browsers can mostly share the same code. Since they use pretty standard HTML/CSS/JavaScript much of the code will also be shared with my app's traditional web services. This sounds like a huge win for bringing rich, native-like experiences to all browsers.
Would be great to see all browsers support a common extensions API. I hope WebExtensions is that API.
I'm glad developers (Edge, Firefox) copy the good model, rather than trying to reinvent the wheel. Even without strict compatibility it would be much easier to do support many browsers, since plugin platform will be conceptually similar.
Firefox Add-on SDK was at best annoying and so inconsistent -- some APIs being sync and some async etc.
I had to prepare an elaborate build system to have a single codebase (well, excluding Safari which is even worse).
Now it'd be possible to move pretty far with Chrome/Firefox/Opera/Edge without the need to hack around the differences.
There is a library made by the guy who created the Reddit Enhanced Suite that helps you create cross browser extensions right now. I've never used it but it did look very promising: https://github.com/honestbleeps/BabelExt
I get that some people may love XUL and whatever, but having never used it, I can't really comment. All I do know is that Jetpack (which Firefox has been pushing) is a sorry excuse for a way to build extensions after you've worked with Chrome. I really hope WebExtensions makes my life easier soon.
Maybe I'm just lazy, but I was very surprised to find that Firefox would create such a technology when more "open web friendly" solutions were possible. I'm sure it's just that XUL is a vestige of a time when the web was still young, but I am going to wait until Web Extensions are released before I attempt to write any extensions for Firefox.
Are there any reasons to keep XUL around (other than lack of apps that were written with it)? It doesn't seem like there are any unique features that couldn't be reproduced using something like chrome's model...
But web plugins are fast becoming obsolete, so it hardly matters.
Users can snapshot the current 40.0 release by copying the installation directory and creating a cloned profile for it with updates disabled. Personally I find the 42.0a2 development channel release to be backwards compatible with all extensions and to have superior memory management.
Anyway, if you're staying on an old release, please use Firefox 38 ESR (or switch to the ESR at Firefox 45, on the assumption that this change won't be complete by March). Sticking with Firefox 40 and disabling security updates seems like a terrible terrible idea.
https://hackademix.net/2015/08/22/webextensions-api-noscript...
Being compatible with Google Chrome isn't very important. Extensions aren't used much on Chrome. I have the same extension for Chrome and Firefox, and Firefox usage is 100x greater.
Reading that made me extremely happy! I'm glad to see cross compatibility is still a goal for browsers.
One reason I've liked and used Firefox is that, especially with extensions, it has been more "my client".
Amidst all the noise over this change, I read into it that -- to some degree -- it is becoming less my client.
Which, to me, seems like another step in Chrome's direction, where I've felt that the client is increasingly the advertiser's client. (And the DRM pushers' client, etc.)
Being my client is what, for me, Firefox has had going for it.
It's my PC. On which I wish to use my client, handling and presenting data in the manner in which I want it handled.
And I'm sure the extensions to the webextensions api will provide enough to do what needs to be done
