Comments (26)
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
from summit.
Notes: https://github.com/yoshuawuyts/knowledge/blob/master/computers/2018-05-31-wasm-notes.md
from summit.
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.
from summit.
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.
from summit.
@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.
from summit.
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.
from summit.
@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.
from summit.
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
from summit.
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.
from summit.
@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.
from summit.
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
from summit.
@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
from summit.
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.
from summit.
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!
from summit.
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!
from summit.
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?
from summit.
@linclark do you also need the talk slot or are you ok with the 1.5h workshop slot?
from summit.
@mcollina We can fill the talk slot if needed, but just having the 1.5 hour workshop slot will also be fine.
from summit.
I will happy to attend and in particular I'm interested with respect how WebAssembly might be integrated and positioning versus N-API.
from summit.
@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?
from summit.
@linclark it works, but I think we can swap Modules with WebAssembly. Would that work for you?
from summit.
@mcollina Ah, that's a good idea. That would be perfect, thanks!
from summit.
Oh hey... come join us for the discussion on zoom
from summit.
Closing issues for sessions that happened. Re-open if that's the wrong thing to do.
from summit.
Did anyone take notes?
from summit.
@yoshuawuyts has extensive notes
from summit.
Related Issues (20)
- Session Proposal: Node.js: Next-10 - Documentation HOT 9
- Session Proposal: Package Maintenance WG session HOT 2
- Session Proposal: Community Health Analytics Discussion HOT 4
- Session Proposal: Security WG Mini-Summit HOT 2
- Session Proposal: Node.js ESM and async_hooks, brainstorm / identify the spurious promises. HOT 7
- Collaborator Summit 2023 - Vancouver, Canada (OpenJS World) HOT 30
- Call for Sessions for the OpenJS Collab Summit 2023 in Vancouver, Canada HOT 1
- Session Proposal: Node.js | Let's automate Node's dependency updates! HOT 9
- Session Proposal: Node.js - The state of Node.js Security HOT 1
- Session Proposal: Node.js Release WG session HOT 1
- Session Proposal: Node.js Tooling Group session HOT 1
- Session Proposal: Node.js Diagnostics WG session HOT 1
- Session Proposal: Node.js - Node.js HTTP parser, what's going on? HOT 1
- Session Proposal: Keeping the Node.js project healthy for the mext 10 years HOT 3
- Session Proposal: jQuery, Too Much of a Good Thing? HOT 3
- Session Proposal: OSS - Zen and the Art of Open Source HOT 1
- Session Proposal: Node.js Technical Priorities for the Next 10 years HOT 8
- Session Proposal: Performance Team Review of the work done HOT 4
- Session Proposal: OpenJS Foundation Standards WG - How to Leverage Foundation + Cross-Project Participation for Standards HOT 2
- Session Proposal: Node.js - New TC39 Modules Proposals
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from summit.