Live data from Hacker News

WebAssembly 101: A developer’s first steps

blog.openbloc.fr

31–40 of 153 posts

Re: WebAssembly 101: A developer’s first steps

#31
post #27
post #26

Earlier quoted context omitted.

I'll concede that I did not spend any time optimizing the C code, the focus was mainly on getting a working wasm module that integrated correctly with th js code. I'll probably have a look on this after work.

Yeah, my point was this example shouldn't be used to judge webasm performance. No point to benchmark "Hello, World!"s.

Thanks for the comment, I added a small paragraph along this line: http://blog.openbloc.fr/webassembly-first-steps/#part4

Re: WebAssembly 101: A developer’s first steps

#34
post #16

I hope they add support for garbage collected languages soon. I don't feel like going back to work with malloc and free after 20 years.

You are not forced to use C or C++. Rust has automatic memory management via its Ownership System. Once you get used to it, it feels a lot like a garbage collected language.

Re: WebAssembly 101: A developer’s first steps

#35
post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

Yes, it's not ideal but remember the ultimate goal, having universal apps that run at native speed and don't have to be constrained to the few large app stores. I'll give up view source for that, assuming the browser VM they run in is secure of course.

Re: WebAssembly 101: A developer’s first steps

#36
post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

I think there is no technical hurdle that is stopping browser manufacturers from downloading the bytecode and showing a disassembled view of it.

Plus nothing is stopping us from popularizing a trend where everybody puts a publicly discoverable debugging hints file (which would make the disassembly easier to read) with a fixed name next to all wasm files.

Re: WebAssembly 101: A developer’s first steps

#37

I'm trying to use asm.js to port Python to JS as a shared library, which would allow us to load and run arbitrary CPython modules (compiled for JS) in the browser. I generate code using emscripten, which is also able to generate WASM (which I'm not using at the moment though). My experience so far: Emscripten is quite mature and compiles even very complex C/C++ code without complaining. Statically linking code works…

> Emscripten is quite mature and compiles even very complex C/C++ code without complaining.

Because it's just Clang with WASM target.

Re: WebAssembly 101: A developer’s first steps

#38
post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try to argue that minified or transpiled js is somehow more readable than wasm. At least it's easier to decompile in theory.

It's absolutely not a "tool for surveillance". How exactly are you going to surveil anything with it?

It's not even a replacement for js, or at least it shouldn't be used that way. No GC for instance. And if you are doing any of the silly things mentioned in your link you have no one to blame but yourself. Like accepting binary blobs without source from contractors.

The link eventually admits you can't do a lot of stuff with js and should use native code. Great, lets just have everyone download and execute untrusted and unsandboxed code. In a way that is completely incompatible across platforms. Maybe we can maked them locked behind "walled gardens" with a ridiculous tax while we're at it. Future generations will laugh at us from their completely wasm based PCs.

Or we can always go back to the old way of doing anything interesting with a browser. By making proprietary, vulnerability ridden plugins. Don't you just miss the days of flash and java applets? Because surely that was a much better solution than wasm.

Re: WebAssembly 101: A developer’s first steps

#39
This can probably only be expected to get better and better. While JS engines are squeezing hard to get some extra performance, WASM is just beginning its life.

It'd be great if someone would make (when it's technological feasible) a way to integrate this natively in node, something like:

const wasm = require('wasm-native');

(async () => {

  const mymodule = await wasm('mymodule.c');

  // use mymodule here
})();

Re: WebAssembly 101: A developer’s first steps

#40

I recommend anyone wanting to experiment with WASM to check out https://github.com/dcodeIO/webassembly which takes a lot of pain out of setting up the toolchain and lets you produce much leaner binaries as well. Also keep an eye on https://github.com/dcodeIO/AssemblyScript :)

How about https://github.com/WebAssembly/binaryen ?
Post reply on HN