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

On Sat, Mar 25, 2017 at 8:44 PM, <[email protected]> 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
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>