Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hello wasm-pack

hacks.mozilla.org

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Hello wasm-pack

#61

Post by steveklabnik »

ndarilek wrote: post #60

Does any of this tooling (I.e. wasm-pack, wasm-bindgen) work with the wasm32-unknown-emscripten target? All of the examples I see use wasm32-unknown-unknown, which is (I think) of limited use to me since I'm linking a fairly complex chain of native libraries against my current wasm target. It seems like cargo-web has lots of this ground covered already. I'm wondering why build these other tools in that case? I don't…

We’re focusing on the unknown target for basically all future work; this stuff can work with the emacripten target, but it might take some PRs to configure it, etc. We’d be open to people hacking on such a thing, but it’s not where the team is putting in any effort.

Re: Hello wasm-pack

#62

Post by illustrioussuit »

probablycorey wrote: post #55
crispyporkbites wrote: post #26

Earlier quoted context omitted.

I have a package on NPM which is only partially implemented, using it in a production app is a bad idea, a quick glance at the source code or the todo section of the readme makes it pretty obvious. I still gets bug reports and npm says it has hundreds of download every month. For anything serious, read the source code, at the very least check your dependencies.

Is this realistic though? Every time you update a dependency you would have to read its source (and its source dependencies, and their source dependencies...) To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.

Theoretically, once something is updated all you would have to do is check the diff. Still tedious though.

Re: Hello wasm-pack

#63

Post by komali2 »

probablycorey wrote: post #55
crispyporkbites wrote: post #26

Earlier quoted context omitted.

I have a package on NPM which is only partially implemented, using it in a production app is a bad idea, a quick glance at the source code or the todo section of the readme makes it pretty obvious. I still gets bug reports and npm says it has hundreds of download every month. For anything serious, read the source code, at the very least check your dependencies.

Is this realistic though? Every time you update a dependency you would have to read its source (and its source dependencies, and their source dependencies...) To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.

Last time I went to one of the Bay Area node meetups, that given meetup was being sponsored by just such a company. Can't remember the name, unfortunately.

The idea was though that you'd feed them your package.json and they'd let you know of any vulnerabilities, iirc. Or maybe they had a private repo of packages they'd checked? Can't remember.

Re: Hello wasm-pack

#64

Post by austincheney »

Mononokay wrote: post #10
vijaybritto wrote: post #5

Earlier quoted context omitted.

You are living in the past tbh. There are tools which make augment the language and it is literally taking over the world now!

It focuses on the lowest common denominator of programmers, and in general the community around it doesn't really care to optimize it or teach the people they attract towards good programming standards.

JavaScript has a low barrier of entry, sure. That doesn't equate to the language being incompetent though. Every language has its incompetent developers. With Node.js you can perform some incredible systems automation cross-OS and it performs extremely efficiently.

Re: Hello wasm-pack

#66

Post by ndarilek »

steveklabnik wrote: post #61
ndarilek wrote: post #60

Does any of this tooling (I.e. wasm-pack, wasm-bindgen) work with the wasm32-unknown-emscripten target? All of the examples I see use wasm32-unknown-unknown, which is (I think) of limited use to me since I'm linking a fairly complex chain of native libraries against my current wasm target. It seems like cargo-web has lots of this ground covered already. I'm wondering why build these other tools in that case? I don't…

We’re focusing on the unknown target for basically all future work; this stuff can work with the emacripten target, but it might take some PRs to configure it, etc. We’d be open to people hacking on such a thing, but it’s not where the team is putting in any effort.

Got it. I assume the unknown target will never be able to link against native libraries beyond those provided by Rust's core itself? I assume the answer is no, but a few years ago I assumed I wouldn't ever be able to do what wasm is letting me now, so I don't want to hold too tightly to those assumptions. :)

Re: Hello wasm-pack

#67

Post by steveklabnik »

k__ wrote: post #65

Are there any benchmarks comparing WASM with Neon on Node.js?

Generally should be faster, it we haven’t made benchmarks. Lots of wasm is client side, Neon is server side. Wasm on the server is coming along too. It’s probably something worth putting together!

Re: Hello wasm-pack

#68

Post by Y_Y »

illustrioussuit wrote: post #62
probablycorey wrote: post #55

Earlier quoted context omitted.

Is this realistic though? Every time you update a dependency you would have to read its source (and its source dependencies, and their source dependencies...) To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.

Theoretically, once something is updated all you would have to do is check the diff. Still tedious though.

I look forward to all the clever exploits that result from benign-looking code being added to benign-looking code.

Re: Hello wasm-pack

#69

Post by axefrog »

Does anyone have a good sense of the current performance impact of crossing the boundary between JS and WASM? I've often thought it'd be great to be able to expose high-performance data structures (and other infrastructure-level stuff) via WASM and then make use of them from JavaScript, but I seem to recall that the interop performance cost is currently too high to make it worth doing, which leaves WASM mainly only useful for long-running tasks, such as game engines, expensive graph layout algorithms and so forth.

Edit: https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac...

> "The wasm-bindgen code generation has been designed with the future host bindings proposal in mind from day 1. As soon as that’s a feature available in WebAssembly, we’ll be able to directly invoke imported functions without any of wasm-bindgen‘s JS shims. Furthermore, this will allow JS engines to aggressively optimize WebAssembly manipulating the DOM as invocations are well-typed and no longer need the argument validation checks that calls from JS need. At that point wasm-bindgen will not only make it easy to work with richer types like strings, but it will also provide best-in-class DOM manipulation performance."

Re: Hello wasm-pack

#70

Post by tomsmeding »

komali2 wrote: post #63
probablycorey wrote: post #55

Earlier quoted context omitted.

Is this realistic though? Every time you update a dependency you would have to read its source (and its source dependencies, and their source dependencies...) To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.

Last time I went to one of the Bay Area node meetups, that given meetup was being sponsored by just such a company. Can't remember the name, unfortunately. The idea was though that you'd feed them your package.json and they'd let you know of any vulnerabilities, iirc. Or maybe they had a private repo of packages they'd checked? Can't remember.

Possibly https://snyk.io/ ?
Post reply on HN