4 ms·

> Lots of people here additionally are up in arms their incredibly specific workflow was upheaveled by a movement to webextensions planned like 2 years in advan

> Lots of people here additionally are up in arms their incredibly specific workflow was upheaveled by a movement to webextensions planned like 2 years in advance. Maybe their incredibly specific workflow involves a piece of multi-million dollar equipment and updating to a new API involves reflashing its firmware for some crazy reason. (alternately, 100 $200 pieces of equipment in hard-to-reach places that must be manually reflashed.) 2 years may be roughly the maximum attention span of a software project, but 5 years seems like a better number for bedrock systems like web browser. I don't mean to trivialize what goes into Firefox, just that backwards compatibility is a big deal and most software companies don't take it seriously enough.

fourthark 9y ago
That's very... specific?
mintplant 9y ago
If Mozilla didn't take backwards compatibility seriously then the JS and layout engines in Firefox could be a whooole lot simpler than they are now... Really, the point of WebExtensions is to establish a well-defined, maintainable API set that can be kept backwards-compatible going forward. Swaths of legacy extensions were already breaking with every release as internal APIs changed. The old system made the e10s (multiprocess) roll-out inordinately more painful and slower than it would have been with WebExtensions, for example.
TheAdamAndChe 9y ago
Perhaps a multi-million dollar piece of equipment shouldn't depend on a third party to maintain legacy protocols. If such R&D could be put into an embedded device, then a little bit of R&D could be put into a proper REST interface so that it could be properly maintained in the future.
mulmen 9y ago
Did Mozilla claim to offer support for their product for that period of time? Why would an embedded developer take a dependency on a third party product that does not have a guaranteed support cycle greater than the life of the device?
damnyou 9y ago
Sounds like a lifecycle management failure. Hope this is a good learning opportunity for next time!

fourthark 9y ago

That's very... specific?

mintplant 9y ago

If Mozilla didn't take backwards compatibility seriously then the JS and layout engines in Firefox could be a whooole lot simpler than they are now... Really, the point of WebExtensions is to establish a well-defined, maintainable API set that can be kept backwards-compatible going forward. Swaths of legacy extensions were already breaking with every release as internal APIs changed. The old system made the e10s (multiprocess) roll-out inordinately more painful and slower than it would have been with WebExtensions, for example.

TheAdamAndChe 9y ago

Perhaps a multi-million dollar piece of equipment shouldn't depend on a third party to maintain legacy protocols. If such R&D could be put into an embedded device, then a little bit of R&D could be put into a proper REST interface so that it could be properly maintained in the future.

mulmen 9y ago

Did Mozilla claim to offer support for their product for that period of time? Why would an embedded developer take a dependency on a third party product that does not have a guaranteed support cycle greater than the life of the device?

damnyou 9y ago

Sounds like a lifecycle management failure. Hope this is a good learning opportunity for next time!