Use Wry in place of a JS runtime?

[SichangHe]

katex-rs is looking for another JS runtime, so I investigated Wry today.

Attractions

• Uses system runtime, fast, light on resources, small, and quick to compile.
• Cross-platform.

Problems

• [FATAL] Can generally only be spawned on the main thread. And then, the event loop blocks the main thread.
• No way to directly execute JS code and get the result. Need to use a window.ipc.postMessage and a handler every time a value is wanted.
• Forces the current window to lose focus despite being set to invisible.

Demo: a REPL-like program

https://github.com/SichangHe/learn_program/blob/a846f80bcffa1b8b30574730206d8e6c6b573110/Rust/wry_test/src/main.rs

Nothing has been done to print the value back, you only get the printing by calling window.ipc.postMessage with a string (other values crash it).

use std::{io::stdin, thread};

use wry::{
    application::{
        event::{Event, WindowEvent},
        event_loop::{ControlFlow, EventLoop, EventLoopProxy},
        window::{Window, WindowBuilder},
    },
    webview::WebViewBuilder,
};

const JS_SCRIPT: &str = r#"
window.ipc.postMessage("Hi");
"#;

fn main() -> wry::Result<()> {
    let event_loop = EventLoop::<String>::with_user_event();

    let window = WindowBuilder::new()
        .with_visible(false)
        .build(&event_loop)?;

    let proxy = event_loop.create_proxy();
    thread::spawn(move || {
        logic(proxy);
    });

    let handler = move |_window: &Window, msg: String| {
        println!("Handler received `{}`", &msg);
    };

    let webview = WebViewBuilder::new(window)?
        .with_html("")?
        .with_ipc_handler(handler)
        .build()?;

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::UserEvent(script) => {
                if let Err(err) = webview.evaluate_script(&script) {
                    eprintln!("{err} executing script `{script}`.\n");
                }
            }
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                ..
            } => *control_flow = ControlFlow::Exit,
            _ => (),
        }
    });
}

fn logic(proxy: EventLoopProxy<String>) {
    eprintln!("Example: sending {JS_SCRIPT}.");
    if let Err(err) = proxy.send_event(JS_SCRIPT.into()) {
        eprintln!("{err} sending script.\n");
    }
    let stdin = stdin();
    loop {
        let mut buf = String::new();
        if let Err(err) = stdin.read_line(&mut buf) {
            eprintln!("{err} reading stdin.\n")
        };
        if let Err(err) = proxy.send_event(buf) {
            eprintln!("{err} sending script.\n");
        }
    }
}

$ cargo r
   Compiling wry_test v0.1.0 (learn_program/Rust/wry_test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s
     Running `target/debug/wry_test`
Example: sending
window.ipc.postMessage("Hi");
.
Handler received `Hi`
var a = { "a": 1, "b": false }; // This is user input
window.ipc.postMessage(JSON.stringify(a)); // This is user input
Handler received `{"a":1,"b":false}`
^C⏎

[amrbashir]

not sure if wry is suitable for this use-case but this PR might interest you #778

[SichangHe]

Yes, if this PR is merged, it would be much easier to use Wry as a JS runtime. Unfortunately, this PR has been hanging for a while.

[amrbashir]

cc @pewsheen, is there anything left in that PR I could help with?

[pewsheen]

cc @pewsheen, is there anything left in that PR I could help with?

Yes, it would be very helpful.

Here are a few things left to do:

• Android support. If it's not necessary for Android at the moment, we can implement this later.
• Adding a callback function argument to evaluate_script. This will introduce a breaking change to the existing code.

[wusyong]

#778 can only support string too because of limitation from Windows. On Windows, it only gives you json as string.

[SichangHe]

#778 can only support string too because of limitation from Windows. On Windows, it only gives you json as string.

This limitation will probably be fine because there are obvious workarounds.
But, the limitation of requiring the main thread cannot be worked around, especially for libraries…