Live data from Hacker News

Hello wasm-pack

hacks.mozilla.org

81–90 of 160 posts

Re: Hello wasm-pack

#81
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!

ah so it isnt in node yet?

Re: Hello wasm-pack

#82

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.

>> I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM

Really? Can you please point me to some documentation about this? I can't mange to find out how to use a wasm compiled library (compiled from C) in C#/mono project (which also compiles to wasm )

Re: Hello wasm-pack

#83
post #33

Earlier quoted context omitted.

The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used si…

>The original runtime was about 60kb in size, that's still unreasonable to add to a library What? What kind of bubble are you working in?

Web applications nowadays depend on hundreds of dependencies. If each one of these dependencies were to have a size of 60kb or more that would be very bad.

Re: Hello wasm-pack

#84
post #57

Earlier quoted context omitted.

I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.

Also, JS is a more suitable target for most managed languages like clojure, typescript, elm, etc.

Well... two of 3 of the languages you provided as example were designed to be transpiled to javascript. I doubt JS is a more suitable target for other languages than an IR like wasm which is being designed to be a compiler target.

Re: Hello wasm-pack

#85

>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.

Is anyone even working on this? I don't remember seeing foreign function bindings in wasm other than for JavaScript. If there are no competitors, JavaScript wins by default, just like C ffi did on server and desktop.

There’s a bunch of uses of wasm outside the browser. I’m personally not a huge fan of crypto currencies, but Etherium is looking to use it as a language for smart contracts, for example. Just like any small language, you can embed the interpreter into whatever and use it for scripting; the spec is written so that this is pretty easy.

That said, none of this means “replacing” JavaScript, no matter what the parent says. It’s a non-goal.

Re: Hello wasm-pack

#86
post #81

Earlier quoted context omitted.

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!

ah so it isnt in node yet?

It is! It’s in the latest LTS even. But in my understanding, it hasn’t been a focus of node, and so sometimes stuff breaks, etc. It’ll get there! Certainly exciting as well.

Re: Hello wasm-pack

#87

Earlier quoted context omitted.

Let's be real, the goal of WebAssembly is to replace JavaScript, but providing alternatives to it. The whole "WASM doesn't replace JS!" thing is pretty much just to placate the "But what's wrong with Javascript?!" crowd.

I disagree from a technical perspective. WASM is a box much like an iframe or a Java applet or Flash media. Therefore the things contained within that box are isolated from the things outside that box. JavaScript, on the other hand, operates outside that box and, with appropriate bindings, can interface with APIs inside that box. The WASM will replace JavaScript argument exists not for any valid technology reasoning,…

I believe you are wrong. WASM has a text version and nothing stops you from using the DOM or the web APIs (given that wasm gets an API). What exactly is the black box? You can use OpenGL in javascript too if that's what you mean by "black box". You can't do anything new in wasm than in JS except you get better performance and more options (language wise).

Re: Hello wasm-pack

#88
post #50
post #48

Earlier quoted context omitted.

Yes, that was my thought too and I was disappointed to see them defending JS at the top of the article. Getting away from dynamic language mush is one of the biggest attractions I have to WASM.

You already got that from asm.js though.

why to use a half baked solution than something designed from the ground up for the job?

Re: Hello wasm-pack

#89

Earlier quoted context omitted.

I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.

>> I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM Really? Can you please point me to some documentation about this? I can't mange to find out how to use a wasm compiled library (compiled from C) in C#/mono project (which also compiles to wasm )

If you manipulate the two code bases to be in the same module https://developer.mozilla.org/en-US/docs/WebAssembly/Underst.... Otherwise, export and import which is also covered on that page

Re: Hello wasm-pack

#90
post #69

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 u…

It depends how much you are expecting, for instance this WebGL demo does about 15k draw calls per frame on my 2014 MBP with integrated Intel GPU before it drops below 60Hz, that's about 1.8 million WebGL calls per second. On this machine, performance of a native executable is quite similar, so the WASM-to-JS overhead isn't big enough to be noticeable for those 1.8m calls/sec. I know, it's not a really useful benchmark, I guess what I want to say is that for most real-world problems the calling overhead shouldn't matter much, since other things will break down first.

PS: link to demo: http://floooh.github.io/oryol/asmjs/DrawCallPerf.html

Post reply on HN