Open gterzian opened 9 months ago
Just found this: https://github.com/servo/servo/pull/21371
Just found this: https://github.com/servo/servo/pull/21371
Thanks for sharing, it's an interesting approach to making the script crate generic: it seems to make script generic over some it's internals, like the dom parser and tokenizer, but it does not seem to deal with how script integrates with externals such as Spidermonkey or Layout. At least that is what I make of it after a quick read.
Like I mention in the PDF attached at the top, I think we first need to isolate how Spidermonkey is used, because obviously one cannot make script generic to all of the use of js::jsapi
and js::rust
that you can see all over script. But an end-goal would see script being generic over a code execution engine, in a similar way to how the linked to PR make script generic over the tokenizer and parser.
It could be worth revisiting that PR, although it would be a separate effort from the one this issue is focused on.
This is an interesting example: https://github.com/chakra-core/ChakraCore/wiki/JavaScript-Runtime-%28JSRT%29-Overview
Looks a bit like the kind of API we'd have to end-up with...
Would it be also possible to run a noscript build of Servo with an empty JS engine? Especially in embedded, low-power contexts I see several use cases for this.
Just in case folks coming here haven't seen it, there's a blog post update related to this: https://servo.org/blog/2024/04/15/spidermonkey/
And here's the report it links to: https://github.com/servo/servo/wiki/Servo-and-SpiderMonkey-Report
Would it be also possible to run a noscript build of Servo with an empty JS engine?
Not currently, but if we reach the stage of abstracting away the engine by way of a trait, that trait could be implemented by what could be "an empty JS engine".
Can we make our JS integration modular, and general? See attached document for a start of the discussion. Servo--modular JS engine.pdf
A checklist(of only one item for now):