Skip to content

Implement a cross-engine WHATWG set of shims #22

Open
@jviotti

Description

@jviotti
Contributor
No description provided.

Activity

tony-go

tony-go commented on Feb 22, 2024

@tony-go
Member

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

tony-go commented on Feb 22, 2024

@tony-go
Member
RaisinTen

RaisinTen commented on Feb 22, 2024

@RaisinTen
Member

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

tony-go commented on Feb 22, 2024

@tony-go
Member

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

RaisinTen commented on Feb 22, 2024

@RaisinTen
Member

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

tony-go

tony-go commented on Feb 22, 2024

@tony-go
Member

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

jviotti commented on Feb 22, 2024

@jviotti
ContributorAuthor

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

robertgzr commented on Feb 27, 2024

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @jviotti@robertgzr@tony-go@RaisinTen

        Issue actions

          Implement a cross-engine WHATWG set of shims · Issue #22 · crossnx/includejs