4 ms·
Atom 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 woul
by wldcordeiro 11y ago
Atom 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?
- Tobu 11y agoI think I would introduce the new APIs through Jetpack (which has a formal separation between the extension proper and the APIs it uses, but ships the implementation for both). Once an extension uses only stabilised APIs (APIs taken from chromium could stabilise first, assuming there aren't too many abstraction leaks), label it as Forward-Compatible on AMO (similar to restartless addons). Help the top extensions port, and start breaking internal APIs more aggressively. Maybe start measuring the latency introduced by cross-process wrappers (assuming the extension that uses them can be determined at runtime), and warn about extensions that use them. The perception that Firefox is slow largely comes from that kind of compatibility hack, and people would probably make an informed choice to speed up their browser.