5 ms·
So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension
by __david__ 11y ago
So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension ecosystem is one of the highlights of Firefox.
I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.
- jasonhansel 11y agoFurthermore, I doubt that such extensions will work without XUL/XPCOM, at least if WebExtensions work like Chrome extensions.
- nwah1 11y agoThat's why they're also working on browser.html so vigorously https://github.com/mozilla/browser.html https://github.com/mozilla/browser.html Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.
- fabrice_d 11y agoExactly. Once all your front-end is in html, including the part that manages tabs, nothing prevent a WebExtension to implement TreeStyleTabs. Also note that the same extension support is landing in Firefox OS (we are working on the missing apis), and will let you install the same extensions everywhere. I understand people mourning xpcom access. You can do fun things with that, but I've also seen my share of horrors when I was reviewing add-ons (let's override the http protocol handler, what could go wrong!).
- wldcordeiro 11y agoExcept for people losing interest in developing for the platform due to all the API churn. By the time all this lands no one will care to implement TreeStyleTabs.
- lewisl9029 11y agoSeeing the vibrant plugin ecosystem revolving around Atom makes me cautiously optimistic for Firefox's future prospects. Implementing the entire interface and plugin system in standard Web technologies will also make plugin development more welcoming to web developers who found XUL development too archaic. In fact, I'm one of those developers, and the first thing I'd do in post-XUL Firefox would be try to create a Tree Style Tabs alternative.
- wldcordeiro 11y agoAtom was a new program though so people started from scratch and had no pre-existing code-bases (unless you count ST3 ports), whereas here Mozilla's change would drive many developers away because they would now need to rewrite addons entirely for the new API or if the API doesn't support what their addon did they're SOL. It seems like a bad way to go about it, they shouldn't deprecate the API till there's feature parity in the new API.
- Tobu 11y agoFeature parity is a meaningless term. Extensions currently have access to the entirety of Firefox internals. That huge internal surface couldn't be stabilised without stopping development entirely.
- pc2g4d 11y agoCouldn't that internal surface be gradually phased out? Make an API that gives you full access to it, then piece-by-piece replace the full access with safer replacements?
- darkmighty 11y agoThey needed to roll this out before they made any changes to extensions!
- steve-howard 11y agoIf I had a nickel for every time the existing solution was deprecated and the "right" solution wasn't ready yet...
- deleted 11y ago[deleted]
- jasonhansel 11y agoThe trouble is that they aren't planning to wait to switch to browser.html. They're deprecating XUL extensions now, without switching to an HTML-based UI first.