mirrors/litbwraw
1
0
Fork 0
mirror of https://github.com/bytedream/litbwraw.git synced 2025-05-09 12:15:13 +02:00
Code Issues Packages Projects Releases Wiki Activity

rephrase some introduction texts

Browse Source
This commit is contained in:
bytedream 2025-03-31 00:47:39 +02:00
parent 9121c75f36
commit 7ad3f77e61
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/introduction.md
View File

@ -15,16 +15,16 @@ print("Hello from WebAssembly Lua!")
### How it works ### How it works
Unlike other Lua VMs in the browser, like [fengari](https://github.com/fengari-lua/fengari) that is completely written in JavaScript, the approach described here uses the official Lua VM to execute code. Unlike other Lua VMs in the browser, like [fengari](https://github.com/fengari-lua/fengari) that is completely written in JavaScript, the approach described here uses the official Lua VM, compiled to WebAssembly, to execute code.
To interact with the Lua VM, the [mlua](https://github.com/mlua-rs/mlua) crate is used which contains all relevant methods to interact with the VM. For interaction with the Lua VM, the [mlua](https://github.com/mlua-rs/mlua) crate is used which contains all relevant methods to interact with the VM.
Because Lua relies on some libc functions that aren't available in WebAssembly (most notably `setjmp`, which is used for error handling), it can't be built with the `wasm32-unknown-unknown` toolchain. Because Lua relies on some libc functions that aren't available in WebAssembly (most notably `setjmp`, which is used for error handling), it can't be built with the `wasm32-unknown-unknown` toolchain.
This limitation is bypassed by using the `wasm32-unknown-emscripten` toolchain instead. This limitation is bypassed by using the `wasm32-unknown-emscripten` toolchain instead.
### Why? ### Why?
In most cases using "web-native" VMs like [fengari](https://github.com/fengari-lua/fengari) is probably the better choice, especially if you just want your code to be run in the browser. In most cases using "web-native" VMs like [fengari](https://github.com/fengari-lua/fengari) are probably the better choice.
But if you have an existing Rust codebase that uses Lua or that is planned to use Lua, and want to run it in the browser, the describe approach might be the right choice. But if you have an existing Rust codebase that uses Lua or that is planned to use Lua, and want to run it additionally in the browser, compiling to WebAssembly might be the right choice.
I personally had the case where user code got executed on a server, and I wanted the users to check their code for correctness in the browser before uploading/submitting it. I personally had the case that user code got executed on a server, and I wanted the users to check their code for correctness in the browser before uploading/submitting it.
The Lua environment had custom defined Rust functions that got exposed to Lua and any user code could use, and I didn't want to rewrite everything in JavaScript. The Lua environment had custom defined Rust functions that got exposed to Lua and any user code could use, and I didn't want to rewrite everything in JavaScript.