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

101–110 of 160 posts

Re: Hello wasm-pack

#101

Post by Schampu »

axefrog wrote: 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…

I did a basic benchmark [0] when partially porting gl-matrix to a near 1:1 wasm equivalent.

There is some overhead but it seems acceptable. I get drops when calling a wasm function with a lot parameters (see .set).

[0] https://maierfelix.github.io/glmw/mat4/

Note: This benchmark is far from perfect but hopefully can provide some insights

Re: Hello wasm-pack

#102

Post by mattnewton »

eridius wrote: post #77
mattnewton wrote: post #72

Earlier quoted context omitted.

Js code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.

The complaint here is that moving from js to wasm means you can't tell if a package is maliciously exfiltrating your sensitive data. That presupposes that you can read and understand the js code. If your argument here is that you can't be confident in your ability to read and understand the js code, then moving to wasm is no longer a problem.

That’s probably true, but I do think that the addition of wasm complicated things. Imagine a js bridge that calls window objects by strings built in the wasm blob, or does anytning using eval. Now the wasm code can call anything js can through this bridge.

Re: Hello wasm-pack

#103

Post by eridius »

mattnewton wrote: post #102
eridius wrote: post #77

Earlier quoted context omitted.

The complaint here is that moving from js to wasm means you can't tell if a package is maliciously exfiltrating your sensitive data. That presupposes that you can read and understand the js code. If your argument here is that you can't be confident in your ability to read and understand the js code, then moving to wasm is no longer a problem.

That’s probably true, but I do think that the addition of wasm complicated things. Imagine a js bridge that calls window objects by strings built in the wasm blob, or does anytning using eval. Now the wasm code can call anything js can through this bridge.

I suppose that's true, but you can also tell that the JS is trying to obfuscate what it's doing and just generally distrust it at that point.

Re: Hello wasm-pack

#104

Post by themihai »

steveklabnik wrote: post #92
themihai wrote: post #91

Earlier quoted context omitted.

>> That said, none of this means “replacing” JavaScript, no matter what the parent says. It’s a non-goal. I believe a better term would be "skipping" javascript than "replacing" javascript. There won't be many rewrites but I'm sure that many people would skip JS on new projects if they would have that option. Why would a Python, Go, Ruby developer choose JavaScript over Python given that their language of choice woul…

One good reason is binary size; JS is going to have the advantage here since it’s runtime is already installed. Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

>> One good reason is binary size; JS is going to have the advantage here since its runtime is already installed.

Yeah, that's true now though I don't think there is something that stops browsers to host a runtime(i.e. a pre-loaded std wasm library + wasm-gc) to help the languages compiled to wasm to reduce their compilation size. The question is really whether the browsers want to make WASM a first class citizen or not.

>> Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

I believe WASM could serve the other lot of people who are not that much into JavaScript. Using the same language on server and browser also reduces friction(i.e. see NodeJS). Personally I believe JS has a such rank based on reach not on merit.

Re: Hello wasm-pack

#105

Post by Rusky »

jashmatthews wrote: post #58
Rusky wrote: post #49

Earlier quoted context omitted.

> It seems only logical that wasm interpreters will be optimizing JITs. Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust. > I guess I don't understand what Wasm is doing that is so much different th…

> Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust. WebAssembly is a VM bytecode for a stack-based VM. Unless you want things to run very, very slowly you still need a JIT to emit native code, rathe…

Yes, I do want a JIT in that sense. I just don't want it doing Javascript-style optimizations with profiling and speculation+deoptimization.

What WebKit is doing is moving in that direction (unfortunately) but it still looks much more like an "-O0 -> -O3" sort of thing than what Javascript gets.

Re: Hello wasm-pack

#106

Post by Rusky »

jnordwick wrote: post #75
jashmatthews wrote: post #58

Earlier quoted context omitted.

> Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust. WebAssembly is a VM bytecode for a stack-based VM. Unless you want things to run very, very slowly you still need a JIT to emit native code, rathe…

So that means wasm has already been inlined and loops unrolled? How will this all interact with vectorization or insurrection choice? I think the VM is going to need to be just like every other VM (once inlining is introduced, why even bother with trying to optimize wasm before the JIT). If wasm is going to be so good, then you could retart java to it? I know a lot of high performance java shops that would love to ge…

You can't get rid of GC in Java without essentially replacing Java.

Re: Hello wasm-pack

#107

Post by steveklabnik »

themihai wrote: post #104
steveklabnik wrote: post #92

Earlier quoted context omitted.

One good reason is binary size; JS is going to have the advantage here since it’s runtime is already installed. Another good reason is that, regardless of what you read on Reddit and Hacker News, a lot of people actually really like JavaScript.

>> One good reason is binary size; JS is going to have the advantage here since its runtime is already installed. Yeah, that's true now though I don't think there is something that stops browsers to host a runtime(i.e. a pre-loaded std wasm library + wasm-gc) to help the languages compiled to wasm to reduce their compilation size. The question is really whether the browsers want to make WASM a first class citizen or…

There’s some complexity, but yeah they could do that. I really doubt it will happen; if we couldn’t get browsers to include jQuery, why would they do this? It’s even harder than that would be.

> reach not on merit

Node’s popularity and success is counter to this notion, IMHO. Seriously, lots of people love JavaScript.

Re: Hello wasm-pack

#108

Post by IshKebab »

austincheney wrote: post #96
IshKebab wrote: post #94

Earlier quoted context omitted.

Currently WASM can't access the DOM. But WASM-native DOM APIs are planned and then you will be able to completely ditch Javascript if you want.

Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started. As others have mentioned there is the hosting bindings API that is well underway, which provides web APIs to the WASM container so that code compiled to WASM can interact with the JavaScript outside it. This doesn't sound like what you are hoping for though. At this time, and for the foreseeable future, there are no…

Code compiled to WASM can already access Javascript outside it. Obviously. Otherwise how could it do anything at all??

> Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started.

I didn't say work had started on it. I just said that it is planned. See here for proof: http://webassembly.org/docs/high-level-goals/

> access browser functionality through the same Web APIs that are accessible to JavaScript

Re: Hello wasm-pack

#109

Post by wvenable »

yougane wrote: post #80
coldtea wrote: post #43

Earlier quoted context omitted.

> The original runtime was about 60kb in size, that's still unreasonable to add to a library. In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...

> Not only will most frameworks and standard JS libs dwarf this The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size. > the average web page size has upped to ~ 3MB these days... This is not an excuse to make web pages' sizes even larger :). Btw, I'm not against the idea of…

There is an idea that the runtime could be hosted from a common CDN and then cached by the browser across applications so you only have to download the runtime once. Combined with browsers caching the compiled versions of the wasm modules, the cost of the large runtime might be pretty minimal in practice.

Re: Hello wasm-pack

#110

Post by dvfjsdhgfv »

Mononokay wrote: post #42
dvfjsdhgfv wrote: post #35

Earlier quoted context omitted.

> it's just a waste of resources for the end-user Frankly, it's not a problem of the language, but the browser. As far as I can tell, none of the popular browsers offer a way to limit resource usage, even though users would clearly benefit from it.

That actually would be a productive way of solving the problem, if limitedly. That'd make me fall much more into the neutral camp on it.

I don't think it ever happens though. Browser vendors focus on performance, and any of these limits would mean degraded experience from the point of the view of the user.
Post reply on HN