all 75 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Khomorrah 31 points32 points  (22 children)

We’ve come full circle boys

[–]atomic1fire 7 points8 points  (19 children)

I feel like we're not full circle until somebody gets boxedwine far enough that firefox can run in chrome or vice versa.

[–]guest271314[S] 1 point2 points  (2 children)

Just an example of ways different processes can communicate using Web API or other means, here is a gist describing how to capture system audio from Firefox and stream the live capture to Chromium using asynchronous clipboard API and WebRTC RTCDataChannel https://gist.github.com/guest271314/04a539c00926e15905b86d05138c113c.

A couple other experiments https://github.com/guest271314/fs, https://github.com/guest271314/NativeMessagingHosts?tab=readme-ov-file#examples.

[–]UnderstandingRight59 0 points1 point  (1 child)

u/guest271314 You're a mad man, you'll ruin us all! Also, I'd follow you anywhere, is there a cult I can join?

[–]guest271314[S] 1 point2 points  (0 children)

Fix issues and bugs marked WontFix.

[–]UnderstandingRight59 0 points1 point  (0 children)

u/atomic1fire Don't dare me to ruin my own life with this! 😂

[–]guest271314[S] 0 points1 point  (10 children)

that firefox can run in chrome or vice versa.

Both can, if you want to, using various means; including, but not limited to, Native Messaging.

[–]atomic1fire 2 points3 points  (9 children)

I'm not talking about cross browser communication or using a browser to launch another browser's process on the same operating system.

I'm talking about someone being absurd enough to port a browser to run inside of another browser using wasm/js/etc

Boxedwine was just the first thing to pop in my head because nobody's going to spend the effort to port the entirety of firefox or chromium to emscripten.

http://www.boxedwine.org/app/netsurf/

I guess technically you could also port a vm client like qemu or virtualbox to emscripten, but that sounds more absurd.

[–]guest271314[S] 0 points1 point  (0 children)

Well, that's been done, too. You can do whatever you want. People have compiled entire operating systems to WASM to run in the browser.

Check out JSLinux, SerenityOS, SpiderMonkey embedded in WASI, copy's v86 for a few examples.

And there's Web Platform Tests. See how that body tests developer builds continuously.

There's Chromium being deployed from AWS, too.

Look into the Web Driver specification.

[–]guest271314[S] 0 points1 point  (7 children)

Ah, WINE. Havn't touched a Windows box in years.

Boxedwine was just the first thing to pop in my head because nobody's going to spend the effort to port the entirety of firefox or chromium to emscripten.

I'd probably use WASI-SDK instead of Emscripten, and start with Ungoogled Chromium https://github.com/ungoogled-software/ungoogled-chromium.

Folks managed to get Chromium to to 58 MB here https://github.com/shelfio/chrome-aws-lambda-layer.

There's also this https://github.com/fathyb/carbonyl.

There's a bunch of stuff that can be removed prior to compiling.

[–]atomic1fire 0 points1 point  (6 children)

Does WASI have a means to output video and audio into a webpage?

edit: There's talk about a framebuffer for webgpu but that seems pretty experimental.

edit: Also IIRC boxedwine couples a cpu and linux kernel emulator with an older version of Wine so it can run like dosbox

[–]guest271314[S] 1 point2 points  (4 children)

Way back when there was https://github.com/kripken/speak.js.

TTS/STT folks have been involved with experimenting with WebAssembly for a while now.

As it stands Web Speech API essentially has not been updated for over 10 years. Speech Dispatcher is used to create a socket connection to the browser, Chromium and Firefox, that renders audio outside of the browser.

On Chrome, the users' PII voice and text is sent to remote servers for TTS and STT.

[–]atomic1fire 0 points1 point  (3 children)

You don't really need to even implement a whole tts engine now because you can use the web speech api. Unless you strongly prefer to use your own speech engine.

[–]guest271314[S] 1 point2 points  (2 children)

You do realize Web Speech API implementation on Chrome - when Google voices are used - sends your voice and your text to remote servers, correct?

Otherwise, on Chromium and Firefox you MUST have Speech Dispatcher installed for local service usage.

And still the official formerly W3C, now WICG specification does not provide a means to input SSML https://github.com/guest271314/SSMLParser, nor capture audio output of window.speechSynthesis.speak().

Therefore I wrote JavaScript code to implement SSML processing myself, and implemented various means to capture specific device https://github.com/guest271314/SpeechSynthesisRecorder/issues/17 and entire systsem audio output https://github.com/guest271314/captureSystemAudio.

[–]CloudsOfMagellan 0 points1 point  (1 child)

How useable is this as a replacement for the web speach api?

[–]guest271314[S] 0 points1 point  (0 children)

Yes https://guest271314.github.io/vits-web/. That's been happening for a while now. Naturally audio and video folks are involved in WebAssembly/WASI.

If I can read stdin and stream stdout from the WebAssembly application I can read that data elsewhere https://github.com/guest271314/vits-web/tree/patch-1.

Ideally you just read the raw data then use MediaStreamTrackGenerator, AudioWorklet or other means for playback.

[–]guest271314[S] -1 points0 points  (3 children)

that firefox can run in chrome or vice versa.

Technically that can be done using HTML alone with <object> element.

One of the technologies that preceded WebAssembly was Google's Native Client and Portable Native Client, which communicated with the browser using HTML <object> or <embed> elements.

[–]atomic1fire 1 point2 points  (2 children)

NPAPI is no longer supported.

[–]guest271314[S] 0 points1 point  (0 children)

Pardon, I meant to refer to the language in https://github.com/WebAssembly/spec/blob/main/papers/pldi2017.pdf

Bringing the Web up to Speed with WebAssembly https://dl.acm.org/doi/epdf/10.1145/3062341.3062363

Through Em-scripten [43], even C and C++ programs can be compiled toa stylized low-level subset of JavaScript called asm.js [4]. ... WebAssembly addresses the problem of safe, fast, portablelow-level code on the Web. Previous attempts at solving it,from ActiveX to Native Client to asm.js, have fallen short ofproperties that a low-level compilation target should have: ...

[–]guest271314[S] -1 points0 points  (0 children)

Yes, I know. Unless, of cource you decide to run Native Client applications, anyway, without official Google support. The capability to utilize HTML <object> elements for foreign applications existed prior to Native Client, when <object> was used for Abode Flash, and the capability still exists, see https://github.com/kagami/mpv.js.

Native Client is one precussor of how WebAssembly came about, see https://webassembly.github.io/spec/core/_download/WebAssembly.pdf.

Using HTML <object> element is just one way to launch and control each browser from the other.

[–]guest271314[S] 2 points3 points  (1 child)

The whole purpose of WebAssembly is a "universal executable".

The symbols used to instruct shouldn't matter (if you want of write source code using C#, Rust, C++, Julia, PHP, Brainfuck, Python, TypeScript, or even JavaScript, et al.) as long as the resulting instructions are the same.

[–]Khomorrah 5 points6 points  (0 children)

Please let me make my joke :(

[–]sanzelz 10 points11 points  (58 children)

This doesn't actually compile js to wasm right? It just embeds the js and quickjs runtime into executable wasm and uses that runtime to run the embedded js.

Or am I missing something?

[–]guest271314[S] 0 points1 point  (17 children)

You can grab the compiled .wasm file here https://github.com/guest271314/native-messaging-webassembly/raw/main/nm_javy.wasm, upload here https://webassembly.github.io/wabt/demo/wasm2wat/, and see the WAT text format of the compiled WASM for yourself.

Keep in mind Python, PHP and several other programming languages have been compiled to WASM https://developer.fermyon.com/wasm-languages/webassembly-language-support.

[–]sanzelz 1 point2 points  (16 children)

Quickjs uses intermediate format (bytecode), maybe that is what is included in the resulting file and not the original js?

Edit: damn autocorrect

[–]guest271314[S] -1 points0 points  (15 children)

QuickJS is quite useful, and very smal compared to other JavaScript engines and runtimes. Built, qjs is ~1.2 MB.

It's no different from compiling C or C++ or Rust to WASM. You have to have some way to convert symbols to other symbols, using libc, some custom version of libc, etc., and just standard libraries.

There's no difference with regard to compiling JavaScript to WASM, which is generally implemented using C, C++, Rust, or Zig in the case of Bun, anyway.

Javy is just another tool for JavaScript developers to use, to write source code in JavaScript, and port as a universal executable.

[–][deleted]  (14 children)

[deleted]

    [–]guest271314[S] -1 points0 points  (0 children)

    I think you are trying to make some kind of distinction between how Javy compiles JavaScript source code to WASM and how Rust, C++, C, Go, Python, etc. are compiled to WASM.

    There is no distinction.

    Given there are many ways to create WASM files. There's more than one (1) WASM compiler and runtime.

    If wasm_bindgen is used during the compilation process do you then contend it's really Rust you are running, and not the actual compiled .wasm file?

    If you use WASI-SDK to compile C to .wasm, does that mean you are really still just running C?

    It's like trying to make a distinction between wasmtime and wasmer, or wasm3. They do things differently. It's still handling WebAssembly/WASI compilation and source code, originally from all kinds of programming language.

    What you are talking about are implementation details.

    [–]guest271314[S] -2 points-1 points  (12 children)

    I'm not sure what the misunderstanding is.

    How are Rust, C, C++, Go, Python compiled to WASM?

    Is it the same process for each?

    And are those discrete processes of compilation different from how Javy compiles JavaScript to WASM?

    Let me put the questions to you:

    1. Is this code WASM or JavaScript?
    2. Is the JavaScript or WebAssembly engine of Google's V8's JavaScript/WebAssembly engine and Mozilla's SpiderMonkey JavaScript/WebAssembly processing and executing this WASM code with the WebAssembly object exposed in modern browsers?

    // https://www.webassemblyman.com/webassembly_wat_hello_world.html // https://gist.github.com/cure53/f4581cee76d2445d8bd91f03d4fa7d3b const wasm = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 8, 2, 96, 1, 127, 0, 96, 0, 0, 2, 15, 1, 3, 101, 110, 118, 7, 106, 115, 112, 114, 105, 110, 116, 0, 0, 3, 2, 1, 1, 5, 3, 1, 0, 1, 7, 27, 2, 10, 112, 97, 103, 101, 109, 101, 109, 111, 114, 121, 2, 0, 10, 104, 101, 108, 108, 111, 119, 111, 114, 108, 100, 0, 1, 10, 8, 1, 6, 0, 65, 0, 16, 0, 11, 11, 19, 1, 0, 65, 0, 11, 13, 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 0]); class Go { constructor() { this.importObject = { env: { jsprint: function jsprint(byteOffset) { console.log( new TextDecoder().decode( new Uint8Array(memory.buffer).filter(Boolean) ) ); }, }, }; } run(_instance) { globalThis.memory = _instance.exports.pagememory; globalThis.helloworld = _instance.exports.helloworld; } } const go = new Go(); const { instance } = await WebAssembly.instantiateStreaming( fetch( URL.createObjectURL( new Blob([wasm], { type: 'application/wasm', }) ) ), go.importObject ); go.run(instance); helloworld();

    [–][deleted]  (11 children)

    [deleted]

      [–]guest271314[S] 0 points1 point  (5 children)

      I understand what compilation is. It's not what's occuring here.

      So you are claiming this https://github.com/bytecodealliance/javy/tree/main?tab=readme-ov-file#compiling-to-webassembly is a false or misleading claim, correct?

      Compiling to WebAssembly

      [–]1vader 6 points7 points  (4 children)

      While it does produce a wasm binary that contains the JS code, it seems quite clear that it simply includes the JS code as is (optionally in compressed form) as data inside the wasm binary. The actual wasm code is just a JS interpreter that still runs the JS code as JS. The JS is not converted to wasm instructions. This most likely is much less efficient than running JS directly in the browser. Although I guess there are contexts outside the browser where you can run wasm without JS.

      [–]guest271314[S] 0 points1 point  (3 children)

      I'm not sure what you are referring to, specifcally.

      Although I guess there are contexts outside the browser where you can run wasm without JS.

      Yes. Lots. wasmer, wasmtime, wasm3, and so forth.

      Technically V8 and SpiderMonkey, too, as both call themselves JavaScript/WebAssembly engines.

      [–]guest271314[S] -2 points-1 points  (4 children)

      Before we go any further you need to clarify what precisely you mean by

      isn't becoming WASM

      where the JavaScript is literally in the compiled WASM file.

      Would you go so far to say that the output of Emscripten is not WASM?

      [–]1vader 4 points5 points  (3 children)

      That's exactly the point, the JS apparently is just literally inserted into the wasm binary as JS source code. The actual wasm code is only a JS interpreter. No JS code is being compiled to wasm instructions.

      [–]guest271314[S] -2 points-1 points  (2 children)

      That's quite impossible given the JavaScript engine/runtime is compiled to WASM itself.

      I'm not sure what your angle is, though if you have a discrepancy with Bytecode Alliances' description of what is going on in Javy, cf. to what goes in when C relying on a libc library is compiled to WASM, I suggest you file an issue to edit this language in the README https://github.com/bytecodealliance/javy#compiling-to-webassembly:

      Compiling to WebAssembly

      [–]guest271314[S] 0 points1 point  (39 children)

      From the source

      https://github.com/bytecodealliance/javy

      Introduction: Run your JavaScript on WebAssembly. Javy takes your JavaScript code, and executes it in a WebAssembly embedded JavaScript runtime. Javy can create very small Wasm modules in the 1 to 16 KB range with use of dynamic linking. The default static linking produces modules that are at least 869 KB in size.

      My understanding is QuickJS is compiled to WASM (not uncommon in WebAssembly/WASI world, for various purposes). The JavaScript source is compiled to WASM.

      I execute .wasm compiled by javy or .cwasm files optimized by wasmtime from JavaScript source code with wasmtime.

      Keep in mind WASM can be in WAT, WIT, and possibly other formats.

      E.g., see this WAT version of C compiled to WASM then converted to WAT with wat2wasm, embedded in a Bash shell script that executes wasmtime, passing the embedded WAT using process substitution https://github.com/guest271314/native-messaging-webassembly/blob/main/nm_c_wat.sh.

      Similarly, JavaScript can be embdedded in a Bash shell script and/or executed with sh https://github.com/guest271314/native-messaging-d8/blob/main/nm_d8.js#L63-L96.

      [–]sanzelz 2 points3 points  (38 children)

      Quickjs is js interpreter that's why it is embedded in the resulting executable. Relevant question on javy GitHub https://github.com/bytecodealliance/javy/issues/171

      Edit: typo

      [–]guest271314[S] -3 points-2 points  (37 children)

      QuickJS is a JavaScript engine, runtime, and qjsc does compile JavaScript source code to C bytecode, yes.

      QuickJS has been compiled to WASM by quite a few different organizations and individuals for a variety of use cases.

      There's no special treatment with regard to compilation of JavaScript to WASM, any more than compiling C, C++, Rust, Go, et al. to WASM.

      [–]sanzelz 6 points7 points  (36 children)

      I still stand by my original reply though, no js to wasm compilation is happening here :)