Using Spidermonkey as a browser JS content back-end

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using Spidermonkey as a browser JS content back-end

mcwerewolf
Hey folks,

I've been looking around for information about this but the documentation on embedding Spidermonkey ends with a simple "hello world" with a bunch of shortcuts taken.

I'm looking to see if it is possible to use SpiderMonkey as a standalone shared library to serve as a back-end component for Pale Moon (which currently uses an in-tree version like Firefox does). Because we've forked off, it currently requires re-implementing what is already implemented in Spidermonkey, and apart from the obvious challenges dealing with refactoring and DOM changes that are woven in, I'm looking into ways to use later Spidermonkey versions to specifically handle web content scripts - potentially separated from chrome scripts. There is very little point in inventing the wheel twice here, IMHO; web content will continue to want to use the latest shinies, but our chrome won't need that.
It seems to me it should be possible to transplant or co-include later Spidermonkey engines for web content since they are able to be used standalone, and that way keep using a central implementation of JS as will be maintained for Firefox (even after Rust becomes a thing).

Unfortunately, there's no real information that I found about how to do such a thing.

I'd appreciate any insights from people who may have done this before, or are more familiar with embedding Spidermonkey.

M.C.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Andrew Sutherland-5
On Sat, Mar 25, 2017, at 11:33 AM, [hidden email] wrote:
> I'm looking
> into ways to use later Spidermonkey versions to specifically handle web
> content scripts - potentially separated from chrome scripts.

I don't think this is feasible.  There is no JS execution context
exposed to content that does not include interaction with the DOM
bindings an through them the entire platform.  And there is no line you
can cut through the implementation that separates chrome-supporting code
from content-supporting code such that they could use different engines.
 Things that it seems a more modern version of JS might easily support
as a drop-in, like Promises, are deeply entangled with the
Gecko-controlled event loop and DOM bindings.

Andrew
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

mcwerewolf
In reply to this post by mcwerewolf
On Saturday, March 25, 2017 at 6:18:41 PM UTC+1, Andrew Sutherland wrote:
> I don't think this is feasible.  There is no JS execution context
> exposed to content that does not include interaction with the DOM
> bindings an through them the entire platform.

Yeah that's what I was afraid of. I'm curious then what the Waterfox developer meant when he said he used the standalone Spidermonkey lib for specialized versions of his browser.

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?
Of course any jsapi changes between versions would have to be addressed then, to make the DOM align with changes in JS, but I think that's going to be less complicated than trying to follow the wildly-twisting development path Spidermonkey has taken (and probably will continue to take). or am I wrong there?

As said it's a little silly to keep re-inventing the wheel when Spidermonkey as-is is already quite complete in terms of how it handles the latest ES standards.

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Andrew Sutherland-5
On Sat, Mar 25, 2017, at 03:44 PM, [hidden email] 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
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jan de Mooij-2
In reply to this post by mcwerewolf
On Sat, Mar 25, 2017 at 8:44 PM, <[hidden email]> wrote:

> Of course any jsapi changes between versions would have to be addressed
> then, to make the DOM align with changes in JS, but I think that's going to
> be less complicated than trying to follow the wildly-twisting development
> path Spidermonkey has taken (and probably will continue to take). or am I
> wrong there?
>

It's still very, very complicated. Some of the JSAPI changes you could work
around or support with some effort, but we have also made large
architectural changes that required lots of changes to both SpiderMonkey
and other parts of Gecko, and you can't easily backport these. Examples are
the JSContext/JSRuntime unification (older branches use multiple contexts
per runtime so you would have to backport all these patches too), the error
handling cleanup (again, lots of non-SpiderMonkey patches to make this
work), the GC has stronger asserts now and to make that work you need to
either disable them or make a lot of platform changes. These are just a few
things that come to mind but there are many more.

Jan


>
> As said it's a little silly to keep re-inventing the wheel when
> Spidermonkey as-is is already quite complete in terms of how it handles the
> latest ES standards.
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

mcwerewolf
In reply to this post by mcwerewolf
Thank you both for providing some more clarification!

On Saturday, March 25, 2017 at 10:14:03 PM UTC+1, Jan de Mooij wrote:
> we have also made large
> architectural changes that required lots of changes to both SpiderMonkey
> and other parts of Gecko, and you can't easily backport these. Examples are
> the JSContext/JSRuntime unification (older branches use multiple contexts
[snip]
The contex/runtime issue alone would be a huge problem, indeed. I wasn't aware that you've unified that -- that would make it completely incompatible with the other back-end components we have. I guess that also explains why so much refactoring has been going on, although I got kind of numbed on that and stopped paying attention since so much of that was just busy-work and pointless renames; the actual work done got buried under all that fluff.

> either disable them or make a lot of platform changes. These are just a few
> things that come to mind but there are many more.

Yes, it looks like I'll have to re-think my approach here. Thanks for the insights!

MC
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Loading...