You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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(IncludeJSCOMPONENTSengine)
Or the shims too:
find_package(IncludeJSCOMPONENTSenginewhatwg)
I then imagine the src/whatwg library exposes functions for attaching themselves into an Engine instance
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
Activity
tony-go commentedon Feb 22, 2024
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:
whatwg/console
,whatwg/timers
tony-go commentedon Feb 22, 2024
Ideas? @jviotti @thundron @bavulapati @RaisinTen
RaisinTen commentedon Feb 22, 2024
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 commentedon Feb 22, 2024
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 commentedon Feb 22, 2024
Yea, I think it makes total sense to allow customizations. 👍
tony-go commentedon Feb 22, 2024
Really like this :)
jviotti commentedon Feb 22, 2024
I think we should have the shims at
src/whatwg
and be an optional library that you can use on top ofsrc/engine
. We can even make use of the component-basedfind_package
integration I added in order to:Pull in just the engine:
Or the shims too:
I then imagine the
src/whatwg
library exposes functions for attaching themselves into anEngine
instancerobertgzr commentedon Feb 27, 2024
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