I'm particularly curious on what parts cheerp adds to their clang+llvm base. Presumably it's something like the C standard target library for WASM/JS?
For reference, here's examples of what you could do with the baseline clang with wasm (but not JS?) [1] [2] [3], referenced from a similar thread on HN.
We do include the C (Musl) and C++ (Clang's libcxx) standard libraries.
And we do have some custom LLVM passes to improve code size and performance (See for example [1] and [2]).
But the main selling point in my opinion is the ability to target JavaScript, and
(almost) freely mix data and code compiled to either JS or Wasm.
Emscripten can also target JS, but it still retains the linear memory model of Wasm (or X86, Arm, ...),
which means that what you get in the end is a big TypedArray and operations on it using basic types.
With Cheerp, code compiled to JS uses an object memory model: a C++ object will become a garbage-collected JS object.
While this has some limitations (you can't do unsafe casts and treat your memory like it's a big array, because it isn't), it allows seamless integration with the Browser (or any third-party) APIs:
- You can store a DOM element directly in your C++ objects (instead of doing everything through tables)
- You can directly manipulate JS Strings instead of constantly converting back and forth to C strings
- You can create nice zero-overhead interfaces to use your C++ classes from manually written JS
- Or, you can just write your whole program in C++, including callbacks for DOM events and whatnot
And you can still compile the peformance-sensitive or type-unsafe parts of your code to Wasm (losing access to some convenience in exchange for speed).
You can get an idea from the Pong tutorial [3], although it's a bit of a contrived example to showcase what can be done.
> a C++ object will become a garbage-collected JS object.
This sounds great for ease-of-use and cross-language binding. But, there's a downside with respect to performance. With Emscripten, you never see any GC events show up in the profiler.
What we usually suggest is to compile most of the application to Wasm (which is also the default), and move the parts that most interact with the outside world to JS.
This can actually result in a speedup if it avoids multiple back-and-forths between JS and Wasm, which is common if you use a Browser/JS api from Wasm.
For reference, here's examples of what you could do with the baseline clang with wasm (but not JS?) [1] [2] [3], referenced from a similar thread on HN.
[1] https://github.com/ern0/howto-wasm-minimal
[2] https://github.com/robrohan/wefx
[3] https://github.com/PetterS/clang-wasm