Good vs. Evil
- Thread starter Randomguy404
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
15. I hope you don't too 
My son's been having nightmares so often that even though he didn't last night, I still woke up at the time he normally would when he's had one.
My son's been having nightmares so often that even though he didn't last night, I still woke up at the time he normally would when he's had one.
12 for -> fork.
I want to change how I compile it to WASM but right now quicksilver (the engine).
And it seems that I have been wrong in thinking its just a one line change. Lets hope it doesn't end up being too bad and that the developer of quicksilver likes the idea of having both build tools work.
I want to change how I compile it to WASM but right now quicksilver (the engine).
When working with rust there are 2 main libraries to bind rust code to JS code so your .WASM builds can communicate with the browser. They also use their own build tools to help you get all the needed glue code and whatnot.
These ways are std-web which uses cargo-web and wasm-bindgen which uses wasm-pack. std-web is more aimed towards allowing you to make entire applications that run inside the browser by exposing every JS function that a browser has to rust. Meanwhile, wasm-bindgen (lets call it bindgen from now on) just gives some functions/macro's so that the programmer can decide what to expose to JS and what JS functions to make available to rust.
You also see this difference in their tools. With cargo web its simply "cargo web start" and you have a simple server setup that automatically compiles your code on changes while wasm-pack just builds your stuff.
For a long time std-web and bindgen where incompatible with each other, but by now this is supposedly fixed with bindgen even becoming a dependency for std-web. The same can not be said for cargo web however, as that fails to create working builds if you have dependencies that rely on bindgen/wasm-pack to do their magic.. Luckily, wasm-pack should correctly build std-web and programs/libraries that depend on it.
The reason I want to change is probably obvious by now: there is a library (an UI one to be exact) that I want to use which decided to go for bindgen rather than std-web.
The reason I need to fork the engine is because it sets the std-web feature on for its rand dependency. This is an artifact from back when bindgen and std-web where still incompatible.
These ways are std-web which uses cargo-web and wasm-bindgen which uses wasm-pack. std-web is more aimed towards allowing you to make entire applications that run inside the browser by exposing every JS function that a browser has to rust. Meanwhile, wasm-bindgen (lets call it bindgen from now on) just gives some functions/macro's so that the programmer can decide what to expose to JS and what JS functions to make available to rust.
You also see this difference in their tools. With cargo web its simply "cargo web start" and you have a simple server setup that automatically compiles your code on changes while wasm-pack just builds your stuff.
For a long time std-web and bindgen where incompatible with each other, but by now this is supposedly fixed with bindgen even becoming a dependency for std-web. The same can not be said for cargo web however, as that fails to create working builds if you have dependencies that rely on bindgen/wasm-pack to do their magic.. Luckily, wasm-pack should correctly build std-web and programs/libraries that depend on it.
The reason I want to change is probably obvious by now: there is a library (an UI one to be exact) that I want to use which decided to go for bindgen rather than std-web.
The reason I need to fork the engine is because it sets the std-web feature on for its rand dependency. This is an artifact from back when bindgen and std-web where still incompatible.
And it seems that I have been wrong in thinking its just a one line change. Lets hope it doesn't end up being too bad and that the developer of quicksilver likes the idea of having both build tools work.