WebAssembly

[linclark]

Anyone want to talk about WebAssembly?

By late May, the work to make WebAssembly modules just plain ES modules will be underway, possibly with prototypes in JS engines (including V8).

There has also been some discussion around using WASM for "native" modules, so we could hash out what the requirements are and what would need to be added to the spec. @lukewagner from the WASM WG will likely be able to join for this if we have any questions about what changes to the spec are possible.

[GlenTiki]

I'd love to if there was interest in the Rust compiling to WASM story. I'm currently prepping a talk about this that might interest people. It's aimed to be introductory to both rust and WASM noobs, like me.

It is however my first tech talk. I'll be giving it at a nodejs meetup the 14th of this month, so I should be able to share the video from it here if people would like to review it, after I've given it once.

Something interesting I've already found:

I've based these benchmarks off @fhinkel's awesome post here: https://medium.com/the-node-js-collection/speed-up-your-node-js-app-with-native-addons-5e76a06f4a40

Repo here: https://github.com/thekemkid/wasm-v-js-v-native

[targos]

I'm in! I contribute to several libraries ported from C++ to WebAssembly and it's not always easy to import them and work with the bindings created with emscripten.

[bmeurer]

@thekemkid Note however that in this particular example a lot of the time difference is due benchmark artifacts, not because WASM or C++ would be faster than JavaScript. That is, the JavaScript version is not semantically equivalent to the C++ version. If you change the C++ version to match the JS code, it'll probably be slower than the JS version.

[GlenTiki]

@bmeurer Could you explain further what you mean by "benchmark artifacts"? My benchmark came with the caveat/gotcha that it is purely a naively implemented rust lib with js-like code that is compiled to wasm to see an immediate perf improvement with a similar module API. I'm sure all three of these in the comparison could be improved greatly with some optimisation! (This is getting off topic, but I'm unsure where to take the conversation, sorry!)

EDIT: just seen your edit! Gotcha

[mhdawson]

I'm interested with respect how WebAssembly might be integrated and positioning versus N-API. It has been discussed in that context a few times.

[bmeurer]

@thekemkid The choice of IEEE754 as the one and only Number type in JavaScript is probably a big factor, whereas C++ gives you int. Not saying that WebAssembly or Rust or C++ cannot be useful, but let's just try to avoid giving the false sense of a performance boost just because you use a different language.

[ashleygwilliams]

i'll def be in Europe (rustfest paris is may 27-29) around this time and could perhaps swing by to talk about the rust->wasm story and packaging wasm for npm if people are interested

[linclark]

For this discussion, we may want to scope it to WebAssembly features that Node needs and keep it language independent. I do think it would be worthwhile to have a separate breakout about Rust+WASM, though.

[ashleygwilliams]

makes sense @linclark, lemme know and i can probably be around. i think there may be a few other convos at the event that i'll need to be in anyways so i might be around regardless.

[ofrobots]

I'm in! I am quite excited about this as this has to

Today native modules are distributed on npm in source code form (C++, Rust etc.) which must be compiled using a compiler toolchain, which must either be present on the end-user/deployment system, or through a build system in a deployment pipeline. Not to mention the expense (install time, cpu resources) to get these modules built. This is specially a concern on PaaS and FaaS services.

Some native module authors try to avoid this end-user complexity by 'shipping' pre-compiled binaries which are typically hosted on a download service somewhere (s3, github, etc.). There are many rough edges with this: need to host multiple binaries for the cross product of {cpu_arch ⨯ OS ⨯ libc ⨯ NODE_MODULE_VERSION}; need to manage and potentially pay for download bandwidth; need to setup complicated build/CI system.

Wasm can be an excellent portable distribution format for Node native modules. We will need some extra features around FFI, host bindings and possibly the execution environment, but it seems worthwhile to explore.

Looking forward to talking about this more at the summit.

/cc @hashseed @flaxgor

[emilbayes]

I'd like to participate as well. I've been using WASM to handwrite a lot of crypto with @mafintosh, and will also be talking about handwriting webassembly at JSConf after the summit. We also maintain sodium-native which is bindings to a cryptographic library written in C, so I have lots of input on what would be required of WASM before it would be able to supplement the prebuilds we currently ship, albeit I am still sceptical of entirely replacing the native bindings. Excited to hear proposals for FFI!

[yoshuawuyts]

Happy to attend! - sat in on some of the Rust allhands WASM sesssions a few weeks ago; would be keen to come hang out again on the Node side too! ✨

[xtuc]

I'm working on the integration in JS bundlers, but haven't planned to come at the summit. Are you interested in having me around @linclark @ashleygwilliams?

[linclark]

@xtuc Thanks for offering. I don't expect that bundlers will be a big part of this discussion, so feel free to stick with your current plans.

[mcollina]

@linclark do you also need the talk slot or are you ok with the 1.5h workshop slot?

[linclark]

@mcollina We can fill the talk slot if needed, but just having the 1.5 hour workshop slot will also be fine.

[NickNaso]

I will happy to attend and in particular I'm interested with respect how WebAssembly might be integrated and positioning versus N-API.

[bmeurer]

I'd like to talk a bit about WASM JIT and how we can support/encourage that use case. We have a prototype of such a library in jaro-sevcik/webassembly-jit, that's based on the support functions for the WebAssembly test suite in the V8 repository.

[linclark]

@mcollina looking at the schedule, I realized there's a big time gap between the talk and the workshop. I'm thinking it probably makes the most sense for us to just kick off the workshop with the talk, which means we won't need the talk slot. Does that work for you all?

[mcollina]

@linclark it works, but I think we can swap Modules with WebAssembly. Would that work for you?

[linclark]

@mcollina Ah, that's a good idea. That would be perfect, thanks!

[MylesBorins]

Oh hey... come join us for the discussion on zoom

https://zoom.us/j/301437498

[Trott]

Closing issues for sessions that happened. Re-open if that's the wrong thing to do.

[benjamingr]

Did anyone take notes?

[emilbayes]

@yoshuawuyts has extensive notes

[yoshuawuyts]

Notes: https://github.com/yoshuawuyts/knowledge/blob/master/computers/2018-05-31-wasm-notes.md