Show HN: Compiling C in the browser using WebAssembly

Couldn’t a tcc or similarly simple C compiler be used instead of a 100MB Clang? Where’s the C to wasm compiler hiding?

100MB on every page refresh just to compile C is a pretty bold direction to go in.

Very cool! I&#x27;ve been watching the &quot;toolchains in Wasm&quot; landscape for a while, and seeing a Clang&#x2F;LLVM toolchain running in Wasm is awesome!<p>YoWASP has also had an LLVM toolchain working in Wasm for a while too[1], although it seems like this version solves the subprocess problem by providing an implementation of `posix_spawn` whereas the YoWASP one uses some patches to avoid subprocesses altogether<p>My biggest question marks around this version are about runtime&#x2F;platform support. As I understand it, this toolchain uses WASIX, which (AFAICT) works with Wasmer&#x27;s own runtime and with a browser shim, but with none of the other runtimes. Are there plans to get WASIX more widely adopted across more runtimes, or to get WASIX caught up to the latest WASI standard (preview2)? Or maybe even better, bring the missing features from WASIX to mainline WASI like `posix_spawn`[2]? I&#x27;d love to be able to adopt this toolchain, but it doesn&#x27;t seem like WASIX support has really caught on across the other runtimes<p>[1]: <a href="https:&#x2F;&#x2F;discourse.llvm.org&#x2F;t&#x2F;rfc-building-llvm-for-webassembly&#x2F;79073" rel="nofollow">https:&#x2F;&#x2F;discourse.llvm.org&#x2F;t&#x2F;rfc-building-llvm-for-webassemb...</a> [2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;WebAssembly&#x2F;WASI&#x2F;issues&#x2F;414">https:&#x2F;&#x2F;github.com&#x2F;WebAssembly&#x2F;WASI&#x2F;issues&#x2F;414</a>

GCC? That&#x27;s easy! :-) What about a complete system? <a href="https:&#x2F;&#x2F;webvm.io" rel="nofollow">https:&#x2F;&#x2F;webvm.io</a><p>Shameless plug: we are hosting a WebVM Hackathon next week (11-14 October) over Discord. For more information: <a href="https:&#x2F;&#x2F;cheerpx.io&#x2F;hackathon" rel="nofollow">https:&#x2F;&#x2F;cheerpx.io&#x2F;hackathon</a>

Cling (the interactive C++ interpreter) should also compile to WASM.<p>There&#x27;s a xeus-cling Jupyter kernel, which supports interactive C++ in notebooks: <a href="https:&#x2F;&#x2F;github.com&#x2F;jupyter-xeus&#x2F;xeus-cling">https:&#x2F;&#x2F;github.com&#x2F;jupyter-xeus&#x2F;xeus-cling</a><p>There&#x27;s not yet a JupyterLite (WASM) kernel for C or C++.

It&#x27;s pretty misleading not to mention the performance overhead. That&#x27;s an obvious downside and quite easy to benchmark. Skipping any discussion of performance feels like sweeping it under the marketing rug :&#x2F;

A few weeks ago, I tried to compile Clang to WebAssembly, but got several different errors, and tried fixing a lot of them, but some of them seemed kind of impossible to fix, so I thought I would try again at a later date. However it seems I will not need to try again. I feel angry that someone made a convenient solution before I did, but also happy, because this probably implies that they made a consistent process to compile Clang for WASM.

Didn&#x27;t Gary Bernhardt do this in 2014? &#x2F;sarcasm

Is it possible&#x2F;already existing to have interactive C++ lessons where the user&#x27;s C++ code is compiled an run client-side in a web page?

You can compile C using JavaScript and target DOS if you are hard core enough. <a href="https:&#x2F;&#x2F;github.com&#x2F;Mati365&#x2F;ts-c-compiler">https:&#x2F;&#x2F;github.com&#x2F;Mati365&#x2F;ts-c-compiler</a>

If what I want is not an executable but a shared library, does this get me anything?<p>I currently have a use case that uses a server running an emscripten build (using SMODULARIZE and some exports, I suppose it’s not a true dylib)

Not really, on Firefox<p><pre><code> panicked at &#x2F;Users&#x2F;syrusakbary&#x2F;Development&#x2F;wasmer&#x2F;lib&#x2F;api&#x2F;src&#x2F;js&#x2F;instance.rs:62:84: called `Result::unwrap()` on an `Err` value: JsValue(Function(bound 846)) Stack: fe&#x2F;_.wbg.__wbg_new_abda76e883ba8a5f@https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;index-CgFg6VHw.js:17:6582 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[1125]:0x2b4276 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[2888]:0x3ab373 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[8254]:0x435ed3 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[4825]:0x3fa7de @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[517]:0x1af753 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[294]:0xbed03 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[2039]:0x34b10e @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[2896]:0x3abaa1 @https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;wasmer_js_bg-BruS15W0.wasm:wasm-function[9393]:0x43fde1 S@https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;index-CgFg6VHw.js:11:424 c@https:&#x2F;&#x2F;wasmer.sh&#x2F;assets&#x2F;index-CgFg6VHw.js:11:264</code></pre>

&gt; note: it requires a 100MB download<p>Is this how big a clang toolchain usually is?

What&#x27;s the use case?

Every few years, new progresses might remind me of this talk by Gary Bernhardt:<p><a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;the-birth-and-death-of-javascript" rel="nofollow">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;the-birth-and-death...</a>

Now all this needs is a simple OS running in a browser, that can edit and compile itself, post the resulting binary onto a WebDAV somewhere, and reload itself from there.<p>Then it becomes a fully self-sustaining OS that can live forever in a browser.

&quot;Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn&#x27;t stop to think if they should.&quot; ....