Add JavaScript evaluation support

[jsjoeio]

I think a solid first step, before #13 (at least the way I'm thinking about it), is to add support for JavaScript since it's relatively straightforward since JS <-> Browser === ❤️

How it works

At a high-level, it works similarly to the current implementation for Python:

• user provides input
• user hits run button
• input -> client to run code -> saves output
• output is displayed in browser for user

How to Implement

1. Create a JavaScriptClient
2. Create a <RunJSCode /> component which comes with an <iframe />
3. Use safe sandbox technique to safely evaluate code
4. Display output in <Editor />

Resources

• Play safely in sandboxed iFrames (thank you @hatemhosny for sharing that here)
  • direct link to example: https://github.com/html5rocks/www.html5rocks.com/blob/master/static/demos/evalbox/index.html
• MDN eval
• Wasmer JS tutorial

Additional Notes

Once we have this implemented, I think adding TypeScript support would be relatively straightforward. All we would need to do is add an extra step to compile the TS -> JS using swc.

(Though there may be a desire to compile it to WASM though and use the WasmClient)

Contributors

We figured this out as a team on a livestream, thanks to:

• @maxcell
• @Dhaiwat10
• @jsjoeio

[Dhaiwat10]

Thanks for putting this together @jsjoeio!

(Though there may be a desire to compile it to WASM though and use the WasmClient)

I think we should def look into this & see what are the benefits of compiling it to Wasm. Anything we learn from there will probably help us get a clearer picture of what Wasm actually does & how it is being used in this project.

[jsjoeio]

I think we should def look into this & see what are the benefits of compiling it to Wasm. Anything we learn from there will probably help us get a clearer picture of what Wasm actually does & how it is being used in this project.

Agreed! Someone on Twitter mentioned Wasmer and I found this tutorial:

In the Hello World example, we covered how to run the helloworld Wasm module, and then read its output

link

It's almost like we want:

• input to be any language [JS, Ruby, Rust, etc.]
• some tool/library to transform [lang] -> WASM
• tool/library to evaluate WASM -> spit out output

I think that would be the best thing to have rather than having these one-off clients which understand 1-2 languages.

[jacobjzhang]

Thanks for putting this together @jsjoeio!

(Though there may be a desire to compile it to WASM though and use the WasmClient)

I think we should def look into this & see what are the benefits of compiling it to Wasm. Anything we learn from there will probably help us get a clearer picture of what Wasm actually does & how it is being used in this project.

To clarify, we're talking about TS -> wasm, right? I was recently catching up via this old chat with some of the Mozilla team where they call out some downfalls of JS -> wasm (grep for "One of the biggest issues there is to get strings from WebAssembly to JavaScript, and the other way around")

[kennethcassel]

I think we should def look into this & see what are the benefits of compiling it to Wasm. Anything we learn from there will probably help us get a clearer picture of what Wasm actually does & how it is being used in this project.

Agreed! Someone on Twitter mentioned Wasmer and I found this tutorial:

In the Hello World example, we covered how to run the helloworld Wasm module, and then read its output

link

It's almost like we want:

• input to be any language [JS, Ruby, Rust, etc.]

• some tool/library to transform [lang] -> WASM

• tool/library to evaluate WASM -> spit out output

I think that would be the best thing to have rather than having these one-off clients which understand 1-2 languages.

Wasmer seems very cool but from what I can tell it's a wasm runtime for many different languages. Which is different than "a way to run many languages via wasm"

So it basically would let you interact and run wasm based tools not only on the browser, but in a go or Python program. (Though I may be wrong about it's full capabilities).

I'd say that flow you stated is pretty close to what we're looking for.

My mental model:

1. Let user input code in a given language
2. Take input code and evaluate it. This may be through a lightweight wasm compiled version of a language (like pyodide), or through a series of compiling and evaluating via some tool running in wasm (like using swc.rs to compile TS, and handing the plain js back to browser)
3. Display output. This output may be a canvas element in some cases (matplotlib) or a series of characters

[Dhaiwat10]

You might want to have a look at this for JS evaluation! (& TS)

#13 (comment)

[zackradisic]

Just wanted to chime in and say that there is not any current way to compile js to wasm, you can read about why that it is here. If we wanted to go the wasm route we would have to compile a JavaScript interpreter to wasm, here's an extensive list of the ones we could use. Most already have build configurations for wasm too!

[jsjoeio]

Talking to @dwwoelfel and @sgrove about JS evaluation and they said they use quickjs-emscripten. Reasons why they chose this:

• There's no way for it to escape the sandbox
• There aren't a ton of other options with the same level of sandboxing