Live data from Hacker News

WebAssembly 101: A developer’s first steps

blog.openbloc.fr

111–120 of 153 posts

Re: WebAssembly 101: A developer’s first steps

#111

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 })();

Why not just write a native extension?

I think they have slightly different advantages:

- WASM is platform independent, so it can easily be precompiled. Which means just the .wasm module needs to be distributed (e.g. inside a npm package). However WASM modules only have access to things that were already available to JS before (no random C/C++ libraries can be included which e.g. call into the OS, no multithreading, etc.). And the toolchain might be at the moment not yet the easiest to set up.

- Node native extensions have quite good tooling support. Write a binding.gyp and the C++ files and everything works pretty smooth. The native code can also do everything that native code is allowed to do on the platform. However node native extensions are platform specific, which means either precompile them for all target plattforms (and each node release) or deliver C/C++ sources which are always compiled on the deployment plattform at npm install time. They also can't be shared between browser and node plattform.

All in all I think they have slightly different usecases:

- Node native extensions for accessing operating system APIs and other libraries which are not already exposed through nodes JS APIs.

- WASM for making existing C/C++ code including full applications (like games) runnable in the browser

- WASM for making modules which speed up pure algorithms (like audio processing) and which can be used on both platforms.

Re: WebAssembly 101: A developer’s first steps

#112

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…

Slightly disconcerted that the first thing webdevs are rushing to do with wasm is to port massive language runtimes to it, continuing the web tradition of piling shit upon shit upon shit. Personally believe that this is totally the wrong idea; compilation or transpilation from intermediate forms is far more interesting and sensible in my view

Re: WebAssembly 101: A developer’s first steps

#113
post #99
post #62

Earlier quoted context omitted.

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth. WebAssembly is the first steps to truly breaking that chokehol…

JavaScript is easy to debug and test, its relative safe, and closures makes it easy to write async programs. Compared to C or C++ you'll have a huge productivity boost with a very small performance penalty. It's also easy to learn compared to other languages. It also doesn't have a standard library which makes it easy to integrate into any platform. For example in Windows OS and other Microsoft products you've been a…

Personally, I'd say Lua and its family of small, easy languages more easily fills those roles.

Not that I doubt some people do voluntarily enjoy JavaScript, but because of the sheer volume of StackOverflow questions, blog posts, micro-techologies, and other assorted attention bestowed upon the language it can be easy to make the logical jump that JavaScript the language is far more popular (in the satisfaction sense) than is actually so.

Re: WebAssembly 101: A developer’s first steps

#115
post #14

Earlier quoted context omitted.

I'd be inclined to agree. Unless the point was not to show off, but that a 30 year-old computer is as fast as the bleeding edge in browser rendering technology.

An unoptimised implementation says nothing about what WASM is eventually capable of. This is an apples-to-oranges comparison unless the WASM app were optimised for speed. (Also parent mentions a 40x25 display on the BBC Micro). Game of Life implementations are ideal case studies for optimisation after Michael Abrash's graphics programming columns.

Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. It's like theoretical vs real world java performance, in limited and optimised benchmarks it might produce fast code, but in real projects it doesn't.

And that's the best case, there are already people in this thread talking about compiling python to web assembly, any performance improvements over the current state of the web are going to be pissed away immediately.

Re: WebAssembly 101: A developer’s first steps

#116
post #115
post #14

Earlier quoted context omitted.

An unoptimised implementation says nothing about what WASM is eventually capable of. This is an apples-to-oranges comparison unless the WASM app were optimised for speed. (Also parent mentions a 40x25 display on the BBC Micro). Game of Life implementations are ideal case studies for optimisation after Michael Abrash's graphics programming columns.

Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. It's like theoretical vs real world java performance, in limited and optimised benchmarks it might produce fast code, but in real projects it doesn't. And that's the best case, there are already people in this thread talking about compiling python to web assembly, any performance impro…

> Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised.

Maybe but not in this kind of performance-sensitive application that spends most of its time in a tight inner loop. Then it really comes down to how optimised that inner loop is.

Re: WebAssembly 101: A developer’s first steps

#117

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level. I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated b…

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

Re: WebAssembly 101: A developer’s first steps

#118
post #117

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level. I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated b…

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

Ha

To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes.

An example is mentioned here ('angels', 'Power Boxes'):

https://www.cl.cam.ac.uk/research/security/capsicum/

The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course.

Capability security has low adoption in part because of the usual catch-22 (adoption breeds adoption), in part because it's a tricky challenge to retrofit, and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.

Re: WebAssembly 101: A developer’s first steps

#120
post #105

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level. I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated b…

You may like browsing through comments by @nickpsecurity (e.g. https://news.ycombinator.com/threads?id=nickpsecurity&next=1... , etc.). He's really knowledgeable about this stuff, and tries to popularize it as much as he can.

On display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this mailing list:

https://groups.google.com/forum/#!forum/cap-talk

Post reply on HN