Understanding Emscripten/ASM.js and the browser sandbox

Question

Sorry for the basic question here. I'm trying to wrap my head around Emscripten, ASM.js, and compiling lower level languages to javascript.

Here is what I don't understand. You can do things in a native C program that you can't (and shouldn't) do in browser based js. For example, in a native app you can access or the file system or shut the computer down.

Suppose I wrote a C program that reads /etc/passwd and then shuts the computer down. Then, I compiled that program to js and popped it in a <script> tag. What would happen when I visit the page with the <script> tag in it? Obviously, it's not going to shut the computer down, but would it even compile?

It just seems to me that javascript running in a browser is so limited compared to lower level languages that I can't see how any meaningful applications can be simply compiled to js without totally breaking it.

Answer 1

Check Emscripten docs . For example, it says:

Applications compiled with Emscripten usually expect synchronous I/O, so Emscripten itself provides file systems with completely synchronous interfaces.

However, due to JavaScript's event-driven nature, most persistent storage options offer only asynchronous interfaces. Emscripten offers multiple file systems that can be mounted with FS.mount() to help deal with persistence depending on the execution context.

And if you scroll down there, you'll find this:

MEMFS

This is the default file system mounted at / when the runtime is initialized. All files exist strictly in-memory, and any data written to them is lost when the page is reloaded.

I believe that this should answer your question. At the end of the day, Emscripten/ASM will try to emulate low-level details with JavaScript-based polyfills.