4 ms·
"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 wh
by 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.