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.
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?
Re:Chrome is Not the Standard
by TheAdamAndChe on Thursday December 21, 2017 @05:09PM
(#15983300)
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.
That's very... specific?
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.