> It clearly states: it targets web assembly. So, this should answer your question I think

Not sure what you're implying.

Here's an example of doing graphics using Rust and WASM - http://cliffle.com/blog/bare-metal-wasm/#making-some-pixels

And another: https://blog.logrocket.com/implement-webassembly-webgl-viewe...

Given that MoonBit is developing their own IDE and it is hosted on the web, I would think one could provide an elegant pipeline to do graphics programming, no?

A WebAssembly runtime is a pure compute+memory sandbox. It can only interact with the host environment in three ways:

1. The host calls an exported WASM function

2. The WASM runtime runs code that calls an imported function

3. The host reads/writes the WASM runtime's memory/globals

In your example, the WASM build process spits out two artifacts - a WASM module and a JS module. The JS module defines the actual JavaScript host functions that manipulate the canvas, and then exposes those functions to the WASM instance.

> I would contribute in this realm becase I'm a graphics and UI person and also enjoy working with new programming languages.

Maybe the case of Makepad will interest you then: https://news.ycombinator.com/item?id=36567681

https://github.com/makepad/makepad

Well, you can do graphics programming in c++ or using a game engine and compile it to Webassembly.. So this language could definitely have a graphics library.

That's only because the host javascript which loads the WASM is exposing functions to do webgl stuff. When you use emscripten to compile C++ is to WASM, part of that equation is the JS runtimes that allow you to call translate openGL calls to Webgl, play sounds etc. It's possible to do with moonbit, but it would require some work on your part.