Re: Using Spidermonkey as a browser JS content back-end

On Sat, Mar 25, 2017, at 03:44 PM, [email protected] wrote:
> Would it be possible to use the standalone Spidermonkey as a drop-in
> replacement for the in-tree version of JS then, to handle both chrome and
> content, or is that just as unfeasible?

A lesser level of infeasible.  Depending on the old release, you might
be able to advance a few versions before it became intractable, but it's
not clear what the point of that would be, especially since there's a
huge difference between getting something to compile and having it work
without crashing.

I think it's worth reconsidering the goal.  The reality of web
development is that web developers target the bundle of functionality
represented by specific browser releases.  Some developers will use
feature detection which provides a degree of wiggle room, but feature
detection usually has varying levels of assumptions baked in that fall
apart over larger time deltas.  Having an up-to-date JS engine is worth
little without its contemporary web platform updates.  For example, I
doubt there is a lot of code out there that will leverage "async"
functions but be okay without fetch() existing.

I think it's far more advisable to concentrate resources on rebasing to
(more) up-to-date Firefox releases or conforming to the functionality
footprints of web browsers with a similar feature set that developers
still target for legacy reasons.  (Which I think is various releases of
IE and older Android browsers, although Android-browser-targeted sites
will probably also assume a mobile form factor, etc.)

Andrew