4 ms·

The toolchain feels pretty clumsy and bloated, there are many intermediary stages that should be done automatically. I hope better alternatives will quickly be

by jokoon 9y ago

The toolchain feels pretty clumsy and bloated, there are many intermediary stages that should be done automatically. I hope better alternatives will quickly become available, or at least some package where you don't to install a thing inside the thing you already downloaded and installed.

umilegenio 9y ago
I agree. At the moment you can use WebAssembly, but it is not exactly user friendly. Effectively they have only build tools that can work inside other tools or as a part of an existing toolchain. However, the end game is to be able to load a WebAssembly module just like you load a JS script. So, we are going to get there, but it will take some time.
emj 9y ago
Agreed since the toolchain is aimed at automatic conversion of C/C++ applications to WebAssembly, emulating filesystems, graphics etc, that makes it feel sluggish for me. At this point I haven't seen many people using WebAssembly directly to develop for the web. Mostly it's people who write to a canvas. This game logic in Rust was a good example of at least some communication with javascript in a non bloated way: https://news.ycombinator.com/item?id=15843064 https://news.ycombinator.com/item?id=15843064 https://aochagavia.github.io/js/embedded-rocket.js https://aochagavia.github.io/js/embedded-rocket.js
- sjmulder 9y ago
  Agreed, back when I got the tooling up and running it generated a whole bunch of things to emulate stdio and such. I couldn't figure out how to make a freestanding wasm library. I wish I could just do `wasmcc -ofoo.wasm foo.c` and get a `foo.wasm` that I can include, without any implicit dependencies and such. Let me supply malloc if I call it. I'm sure there'd be libc-lite libraries in no time (if they aren't there already, I'm out of date).
azakai 9y ago
What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.
- jokoon 9y ago
  I'd prefer a C++ compiler that directly compiles to wasm. Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake. I have read tutorials about binaryen and emscriptem, I did not have a fast computer nor a fast internet connexion, and it was so painful and unclear I gave up. I get that asm.js was great, but it was mostly a hack, wasm should be much cleaner. I don't understand the choice of emscripten.
  - deleted 9y ago
    [deleted]
  - azakai 9y ago
    I'd like to understand you better, I don't think I do yet. From the user's perspective, isn't emcc a C++ compiler that directly compiles to wasm? There are some internal IRs along the way, but you shouldn't notice them, like you don't notice the GIMPLE IR when using gcc? The emscripten sdk isn't small, that's true, but that's because LLVM+clang are not small, plus the musl libc and libc++ are not small either. But all those pieces are necessary in order to provide emcc which can compile C++ to wasm. So it can't be just a single repo, multiple components are needed here - in fact, regardless of emscripten, more will be needed soon since the LLVM wasm backend will depend on the lld linker. What we can maybe do to make this unavoidable complexity seem simpler, is to compile all the necessary things into wasm, and have a single repo containing those builds. So it would contain clang compiled to wasm, lld compiled to wasm, etc. Then the user would check out that one repo and have all the tools immediately usable, on any OS. The wasm builds would be a little slower than native ones, but perhaps the ease of use would justify that - what do you think?

by jokoon 9y ago

umilegenio 9y ago

I agree. At the moment you can use WebAssembly, but it is not exactly user friendly. Effectively they have only build tools that can work inside other tools or as a part of an existing toolchain. However, the end game is to be able to load a WebAssembly module just like you load a JS script. So, we are going to get there, but it will take some time.

emj 9y ago

Agreed since the toolchain is aimed at automatic conversion of C/C++ applications to WebAssembly, emulating filesystems, graphics etc, that makes it feel sluggish for me. At this point I haven't seen many people using WebAssembly directly to develop for the web. Mostly it's people who write to a canvas. This game logic in Rust was a good example of at least some communication with javascript in a non bloated way: https://news.ycombinator.com/item?id=15843064 https://news.ycombinator.com/item?id=15843064 https://aochagavia.github.io/js/embedded-rocket.js https://aochagavia.github.io/js/embedded-rocket.js

sjmulder 9y ago
Agreed, back when I got the tooling up and running it generated a whole bunch of things to emulate stdio and such. I couldn't figure out how to make a freestanding wasm library. I wish I could just do `wasmcc -ofoo.wasm foo.c` and get a `foo.wasm` that I can include, without any implicit dependencies and such. Let me supply malloc if I call it. I'm sure there'd be libc-lite libraries in no time (if they aren't there already, I'm out of date).

azakai 9y ago

What felt clumsy or bloated to you in the toolchain? We'd love to improve it, specific feedback would be very helpful.

jokoon 9y ago
I'd prefer a C++ compiler that directly compiles to wasm. Would it be either a G++ or clang++ module, but something a lot more straightforward and simple. No intermediary, no multiple dependencies. Either a simple compiler binary, and if not possible (although I still wonder why developer never release both source code AND binaries), provide a single downloadable repo that I can build using cmake. I have read tutorials about binaryen and emscriptem, I did not have a fast computer nor a fast internet connexion, and it was so painful and unclear I gave up. I get that asm.js was great, but it was mostly a hack, wasm should be much cleaner. I don't understand the choice of emscripten.
- deleted 9y ago
  [deleted]
- azakai 9y ago
  I'd like to understand you better, I don't think I do yet. From the user's perspective, isn't emcc a C++ compiler that directly compiles to wasm? There are some internal IRs along the way, but you shouldn't notice them, like you don't notice the GIMPLE IR when using gcc? The emscripten sdk isn't small, that's true, but that's because LLVM+clang are not small, plus the musl libc and libc++ are not small either. But all those pieces are necessary in order to provide emcc which can compile C++ to wasm. So it can't be just a single repo, multiple components are needed here - in fact, regardless of emscripten, more will be needed soon since the LLVM wasm backend will depend on the lld linker. What we can maybe do to make this unavoidable complexity seem simpler, is to compile all the necessary things into wasm, and have a single repo containing those builds. So it would contain clang compiled to wasm, lld compiled to wasm, etc. Then the user would check out that one repo and have all the tools immediately usable, on any OS. The wasm builds would be a little slower than native ones, but perhaps the ease of use would justify that - what do you think?