Implement a cross-engine WHATWG set of shims

[jviotti]

No description provided.

[tony-go]

Should this be directly in the example folder maybe?

If we are a library that helps people write their runtime, I don't know if we should add more support for these APIs.

Here are the two solutions that I see:

• We let includejs empty as we could, and then we create another repo, a real runtime that could be the proof of includejs usage
• Or we could create standalone modules that users can opt-in whatwg/console, whatwg/timers

[tony-go]

Ideas? @jviotti @thundron @bavulapati @RaisinTen

[RaisinTen]

Most of the WHATWG APIs are expected to be available in pretty much all JS runtimes, so I think it makes sense to implement those here. I can see how this can get tricky with stuff like timers. If we include it here, this would get tied with an event loop because having timers would mean running async code. An implementation that is not too coupled with an event loop would expose an interface that would need to be satisfied by whatever event loop the user wants to use.

[tony-go]

yeah, it makes sense, but I wonder if someone wants to do its own implementation of timers for whatever reason, could we have a way to opt out?

[RaisinTen]

Yea, I think it makes total sense to allow customizations. 👍

[tony-go]

An implementation that is not too coupled with an event loop would expose an interface that would need to be satisfied by whatever event loop the user wants to use.

Really like this :)

[jviotti]

I think we should have the shims at src/whatwg and be an optional library that you can use on top of src/engine. We can even make use of the component-based find_package integration I added in order to:

Pull in just the engine:

find_package(IncludeJS COMPONENTS engine)

Or the shims too:

find_package(IncludeJS COMPONENTS engine whatwg)

I then imagine the src/whatwg library exposes functions for attaching themselves into an Engine instance

[robertgzr]

expose an interface that would need to be satisfied by whatever event loop the user wants to use

sounds like we probably want to define that interface as part of includejs and provide the mvp interface on top of appkit, win32 and glib?
something like dispatch(callback) would probably be sufficient for a start...

the only thing that is not clear to me here is how the integrating side would hook such an intermediate into it's own event loop. for the big toolkits mentioned above it might not be a hard requirement, but if an app drives it's own event loop with libuv for example they would have to be able to implement our dispatch interface or (ideally) plug in a libuv implementation we provide