29 ms·

"WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like." In practice, it does not. It's too low level,

"WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like." In practice, it does not. It's too low level, and the APIs to access browser features are not available, so you have to go through seriously ugly APIs and just do it in JS anyhow. So if you have to go to JS to do pretty much everything, why are we using WASM again? Performance? Is performance the issue? Because if it is, isn't there maybe better ways of solving that problem? It's certainly not for portability, we already have that. To make 'web development available to C coders' ... Not sure that's it since they will invariably have to know web browsers anyhow ... WASM is a great idea that won't gather steam until there are direct APIS. Which is on the roadmap I think. I'd suggest just trying to build a simple WA, or even trying to make a simple app out of WA. Things look different then. It's a nice dream to have, we're still a ways off.

klodolph 9y ago
This is a straw man argument. WASM is obviously not a compelling alternative to JS. There are few people crazy enough to write web apps in C. Is that the "nice dream to have"? However, I can think of two very compelling use cases for WASM. As an addition to JS, it gives JS programmers access to a wealth of libraries and programs written in other languages. Codecs and compression algorithms, linear algebra libraries, image and audio processing, and a million other things have good libraries that just don't happen to be written in JavaScript. Adding a WASM blob as a library you can call from JS is a huge success. Suddenly you can do tons of client-side processing that was too prohibitive before (from an engineering cost standpoint). As an alternative to Flash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript. Having used WASM personally, I can say with conviction that it is a compelling addition to the open web.
- alexasmyths 9y ago
  "lash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript." No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. Ok - so accessing C libs is useful? Are bindings from other languages to C considered to be really an important things for those languages? Was there a specific set of libs that we were angling for? Does it even make sense to do those things in the browser? And what about the limitations - i.e. having to pass data into and out of the WASM container - does that play well with usage of 'codecs'? Maybe not. So why again does WASM exist? What as the compelling use case? Flash/UX is definitely not it. I don't see any real uses cases for things like codes, nor was I seeing demand. So where is the market/product need? And use case? This is cool tech that's a long way off from being useful in the real world. Having gone through the pain of writing my own little app, I realized that it's still fairly bleeding edge. I will go back to it when there are deeper APIs between JS and C, are the toolchain is more stable.
  - fourthark 9y ago
    > Ok - so accessing C libs is useful? Yes. > Are bindings from other languages to C considered to be really an important things for those languages? Definitely! > Was there a specific set of libs that we were angling for? No, there are too many to count. For example, I am looking forward to using network visualization libraries that no one here has heard of. They would be very difficult to port from C++ to JS. > Does it even make sense to do those things in the browser? Yes.
  - klodolph 9y ago
    > No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. That's false. When writing a game, you interact with APIs in your implementation language (e.g. SDL). > Are bindings from other languages to C considered to be really an important things for those languages? Yes, it's a fairly critical feature, which is why successful languages almost universally have a C FFI. Some languages have several FFIs to choose from, and others can even integrate with the C preprocessor. So many libraries that we use on a daily basis are written in other languages than the languages we use, and that's just how modern programming works. > So where is the market/product need? And use case? > This is cool tech that's a long way off from being useful in the real world. It will happen faster than you think. Some JS developer somewhere will want to use a native library. They will want to use it badly enough to port it to WASM, write a JS wrapper interface, and upload the whole thing to NPM. Suddenly, a C++ developer with no knowledge of JS will be delivering features to front-end developers with no knowledge of C++, all thanks to some third developer who put in the effort for the WASM port. Which is how it already works everywhere else, so it shouldn't be a surprise. For example, you can use SDL from C#, even if you don't know C and the SDL developers don't know C#. All because some guy with a bit of knowledge about P/Invoke figured out how to copy data in and out of the C# runtime to make some SDL bindings, just the same way you'd have to do it with WASM. I mean, you can complain about problems with copying data in and out of WASM, but it already works that way with other FFIs.
    - alexasmyths 9y ago
      "That's false. When writing a game, you interact with APIs in your implementation language (e.g. SDL)." Ultimately - information must not only be passed through an ugly memory-reference API, but anything that happens on the screen, must happen in JS. Ok, sure, you can abstract it all away, but that doesn't change the fact of the matter. It would be more powerful and efficient to be able to do stuff natively inside the container. " Some JS developer somewhere will want to use a native library. They will want to use it badly enough to port it to WASM, write a JS wrapper interface, and upload the whole thing to NPM. Suddenly, a C++ developer with no knowledge of JS will be delivering features to front-end developers with no knowledge of C++, all thanks to some third developer who put in the effort for the WASM port." Agreed - but I still don't think we are quite there yet.

klodolph 9y ago

This is a straw man argument. WASM is obviously not a compelling alternative to JS. There are few people crazy enough to write web apps in C. Is that the "nice dream to have"? However, I can think of two very compelling use cases for WASM. As an addition to JS, it gives JS programmers access to a wealth of libraries and programs written in other languages. Codecs and compression algorithms, linear algebra libraries, image and audio processing, and a million other things have good libraries that just don't happen to be written in JavaScript. Adding a WASM blob as a library you can call from JS is a huge success. Suddenly you can do tons of client-side processing that was too prohibitive before (from an engineering cost standpoint). As an alternative to Flash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript. Having used WASM personally, I can say with conviction that it is a compelling addition to the open web.

alexasmyths 9y ago
"lash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript." No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. Ok - so accessing C libs is useful? Are bindings from other languages to C considered to be really an important things for those languages? Was there a specific set of libs that we were angling for? Does it even make sense to do those things in the browser? And what about the limitations - i.e. having to pass data into and out of the WASM container - does that play well with usage of 'codecs'? Maybe not. So why again does WASM exist? What as the compelling use case? Flash/UX is definitely not it. I don't see any real uses cases for things like codes, nor was I seeing demand. So where is the market/product need? And use case? This is cool tech that's a long way off from being useful in the real world. Having gone through the pain of writing my own little app, I realized that it's still fairly bleeding edge. I will go back to it when there are deeper APIs between JS and C, are the toolchain is more stable.
- fourthark 9y ago
  > Ok - so accessing C libs is useful? Yes. > Are bindings from other languages to C considered to be really an important things for those languages? Definitely! > Was there a specific set of libs that we were angling for? No, there are too many to count. For example, I am looking forward to using network visualization libraries that no one here has heard of. They would be very difficult to port from C++ to JS. > Does it even make sense to do those things in the browser? Yes.
- klodolph 9y ago
  > No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. That's false. When writing a game, you interact with APIs in your implementation language (e.g. SDL). > Are bindings from other languages to C considered to be really an important things for those languages? Yes, it's a fairly critical feature, which is why successful languages almost universally have a C FFI. Some languages have several FFIs to choose from, and others can even integrate with the C preprocessor. So many libraries that we use on a daily basis are written in other languages than the languages we use, and that's just how modern programming works. > So where is the market/product need? And use case? > This is cool tech that's a long way off from being useful in the real world. It will happen faster than you think. Some JS developer somewhere will want to use a native library. They will want to use it badly enough to port it to WASM, write a JS wrapper interface, and upload the whole thing to NPM. Suddenly, a C++ developer with no knowledge of JS will be delivering features to front-end developers with no knowledge of C++, all thanks to some third developer who put in the effort for the WASM port. Which is how it already works everywhere else, so it shouldn't be a surprise. For example, you can use SDL from C#, even if you don't know C and the SDL developers don't know C#. All because some guy with a bit of knowledge about P/Invoke figured out how to copy data in and out of the C# runtime to make some SDL bindings, just the same way you'd have to do it with WASM. I mean, you can complain about problems with copying data in and out of WASM, but it already works that way with other FFIs.
  - alexasmyths 9y ago
    "That's false. When writing a game, you interact with APIs in your implementation language (e.g. SDL)." Ultimately - information must not only be passed through an ugly memory-reference API, but anything that happens on the screen, must happen in JS. Ok, sure, you can abstract it all away, but that doesn't change the fact of the matter. It would be more powerful and efficient to be able to do stuff natively inside the container. " Some JS developer somewhere will want to use a native library. They will want to use it badly enough to port it to WASM, write a JS wrapper interface, and upload the whole thing to NPM. Suddenly, a C++ developer with no knowledge of JS will be delivering features to front-end developers with no knowledge of C++, all thanks to some third developer who put in the effort for the WASM port." Agreed - but I still don't think we are quite there yet.