Scope of boa_runtime

[xubaiwang]

I'm currently adding Web API bindings to boa (e.g. WebGPU, WebAssembly).

Should I contribute directly into boa_runtime, or alternatively, maintain it as a separate project, resembling how llrt extends rquickjs?

[nekevss]

TL;DR: I don't recall a scope being discussed. We always welcome contributions to Boa! So feel free to submit a PR for the features.

I can't recall off the top of my head if we have ever discussed the exact scope of boa_runtime. I think I'd defer to @hansl on that one as he's worked more on the boa_runtime crate.

For background, the runtime crate specifically started out as a crate to separate out runtime specific functionality from the core ECMAScript implementation. Before this we had the console implementation directly in the engine, and it didn't make sense for that to live there. As time has passed, there have been more Web API features added to the crate, and I suspect more Web API features will be implemented over time.

For me, I'm not entirely sure there is a way for us to say we will accept some of the Web API implemented over another Web API. If boa_runtime begins to get too large, then we could look to separate it into it's own repository or project at that time. But I think we still have much further to go until we reach that point.

I'd say feel free to contribute those features to the boa_runtime crate if you'd like 😄

[hansl]

Hi @xubaiwang,

I'd say if it's part of MDN one way or another (but not part of tc39), we should add it to boa_runtime. For example, I'm in the process of adding web workers (including postMessage, but not EventListener yet).

When boa_runtime is too large and causes problems to Boa's core development, we can also move it to its own repo. I remember some discussions about that.

So basically, if you can point to the MDN as a specification / documentation of your implementation, and see that it passes some WPT (https://web-platform-tests.org/) for following the w3c standard, then it should be good enough to have a PR in boa_runtime. We have a tool already to run WPT, I can help you with that.

So I agree with @nekevss, contributions welcome!

[xubaiwang]

which is why we don't have an "event loop" on that crate

@jedel1043 I have a question: why event loop is not a necessity in Web APIs?

For example:

• in fetch (future async version) we need to drive the hyper::Conection
• in WebGPU, Device::poll has to be called after Buffer::map_async. Otherwise it need be spawned on a new thread (how Deno does)

Although they can be written to support any JobQueue including the builtin Simple one. Isn't the JobQueue itself kind of a event loop?

[jedel1043]

Hmmm, if even the w3c APIs will need an event loop in the future, maybe it would be worth to expand the scope of boa_runtime and make it a fully fledged runtime. @hansl thoughts?

Isn't the JobQueue itself kind of a event loop?

Yes, it is a trait that was designed to represent the event loop of a runtime.

[hansl]

fetch currently uses the job queue. It already uses Async jobs, although our current fetchers are not fully async yet.

The expectation for an event loop is that JS tasks and microtasks should be ran (using context.run_jobs() or its friends), then events happen in the host application, then the host, once in a while, calls context.run_jobs() (or its friends) to run another loop of tasks and microtasks. The Event loop is entirely the responsibility of the host and we assume run_jobs() will be called often enough (e.g. Chrome calls it a maximum of 60 times a seconds).

Any tasks that require polling status should be run in a job on the job queue.

I should write a blog post about it TBH. This might come often.

[hansl]

Firefox is only calling into JavaScript about 16 times a second maximum. Less so for background tabs.

It's the nature of JavaScript. Event loops are handled by the Host (e.g. Browser).

[NickTomlin]

Any tasks that require polling status should be run in a job on the job queue.
I should write a blog post about it TBH. This might come often.

I've been investigating boa / rust as a replacement for https://github.com/justjake/quickjs-emscripten (and other quickjs wrappers) and more details on the "BYO event loop" pattern would be great!

My use case is a "plugin model" where a host runtime (Node, the JVM, etc) could invoke user authored code via BOA.

As a related aside, I'm personally less concerned with having a 1:1 equivalent with a runtime like node but would love to have a bare minimum contract to use boa via WASM that would allow providing behavior for things like fetch in the way that module loader allows managing modules. Projects like starling monkey are taking the "batteries included" approach and boa appeals to me because it is conceivably a lot lighter and would allow mixing and matching higher level features.