wajic VS pacman.zig

This is a slim alternative to Emscripten which focuses only on the C/C++ <=> JS interoperability part:

https://github.com/schellingb/wajic

There's actually a super interesting project called wajic here:

https://github.com/schellingb/wajic

It's basically clang plus wasm-opt and some magic pixie dust which enables some of the most important features of Emscripten, but without the whole 'technology zoo' :)

There's now an interesting alternative to Emscripten called WaJIC:

https://github.com/schellingb/wajic

Enables most of the "Emscripten magic" (like embedding Javascript code into C/C++ files), but in a more bare bones package (apart from clang it essentially just uses the wasm-opt tool from Binaryen for post-processing).

(to be clear, wajic has fewer out-of-the-box features than Emscripten, but it might be an alternative for very small projects which don't need all the compatibility shims which are coming with Emscripten, while still providing tools for calling between C/C++ and JS.

Since I haven't seen it mentioned in the comments yet, here's another interesting project in the general area of "WASM without Emscripten":

https://github.com/schellingb/wajic

This provides an alternative implementation of Emscripten's EM_JS() magic (embed Javascript snippets right in the C/C++ source code), but without the Emscripten SDK. It still needs some additional tools next to Clang, so it sits somewhere between "pure Clang" and "full Emscripten SDK".

Alas, although there is WebAssembly support in the original dos-like, it is still not supported in the bindings for Rust. It would require a Rust toolchain to integrate with WAjic, which I am pretty much unfamiliar with. If you have any idea on how to achieve this, I would love to know.

For a somewhat more complete example which runs in browsers, check out my little pacman.zig toy project [0]. This is cheating a bit by using Emscripten toolchain as 'sysroot' (needed for the Emscripten headers), and the Emscripten linker to create the html+js+wasm output file, but the actual code is all compiled with the Zig compiler.

The interesting part is that the platform abstraction is provided by the sokol headers [1], with auto-generated Zig bindings [2]. It's interesting because the C headers use "Emscripten magic" (mainly embedding Javascript snippets in the C sources via the EM_JS() macro), and the Zig compiler is able to compile this (when it has access to the Emscripten headers).

It would be nice if the "Emscripten platform" could get the same type of cross-compilation support as the desktop platforms eventually, but apart from bundling the Emscripten headers, this would also require to implement some of the "Emscripten magic" in the linker step.

Maybe projects like WaJIC can help with this (this basically implements the "Emscripten magic" of embedding Javascript snippets in C/C++ source code, but without Emscripten (only the wasm-opt tool is needed AFAIK).

Anyway... it's a lot of fun to tinker around with this stuff in Zig, and watch how it's all taking shape :)

[0] https://github.com/floooh/pacman.zig

My advice would be: to learn a new language, start writing some non-trivial projects in it (a few thousand lines of code or so). In some languages (like Python), the standard library is the actually important feature, in other languages (like C), it better to mostly ignore the stdlib. Example: I started learning Zig by writing a Pacman clone (https://github.com/floooh/pacman.zig) and a home computer emulator (https://github.com/floooh/kc85.zig), the Pacman clone doesn't use any Zig stdlib features at all, and the emulator only minimally for parsing command line args and loading data from files.

Zig's stdlib is much more useful than C's, but it's still entirely possible to write useful programs without it and instead focus on learning Zig's language features first.

But on the other extreme, the whole point why I learned Python was its "batteries included" standard library.