Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modular JS/execution engine #30863

Open
1 task
gterzian opened this issue Dec 12, 2023 · 6 comments
Open
1 task

Modular JS/execution engine #30863

gterzian opened this issue Dec 12, 2023 · 6 comments
Labels
B-meta This issue tracks the status of multiple, related pieces of work L-javascript Javascript is required

Comments

@gterzian
Copy link
Member

gterzian commented Dec 12, 2023

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):

@gterzian gterzian added B-meta This issue tracks the status of multiple, related pieces of work modularity labels Dec 12, 2023
@gterzian gterzian added the L-javascript Javascript is required label Dec 12, 2023
@sagudev
Copy link
Member

sagudev commented Dec 15, 2023

Just found this: #21371

@gterzian
Copy link
Member Author

Just found this: #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.

@gterzian
Copy link
Member Author

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...

@darkdragon-001
Copy link

darkdragon-001 commented Apr 15, 2024

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.

@jokeyrhyme
Copy link

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

@gterzian
Copy link
Member Author

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-meta This issue tracks the status of multiple, related pieces of work L-javascript Javascript is required
Projects
Status: No status
Development

No branches or pull requests

5 participants