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

121–130 of 160 posts

Re: Hello wasm-pack

#121

Post by krapp »

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…

>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.

And yet somehow thanks to NodeJS, javascript development seems to have gotten exponentially more complex.

Re: Hello wasm-pack

#122

Post by krapp »

plurgid wrote: post #34
alex_duf wrote: post #15

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

> when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it.

No more than it was when Flash was a thing, or Java applets, or Silverlight. The world has been presented with numerous opportunities to turn the web into nothing but binaries, it hasn't happened.

>Unless maybe I'm missing something.

You're missing the part where someone would have to put a gun to everyone's head and force them to rewrite the entire web as WASM blobs, then force all of the browsers to be redesigned, and the servers, so that HTML and plaintext are deprecated, for your doomsday scenario to be even remotely plausible.

Re: Hello wasm-pack

#123

Post by darepublic »

eridius wrote: post #71
mpolichette wrote: post #18

I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect. https://hackernoon.com/im-harvesting-credit-card-numbers-and...

Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.

Wouldn't the network tab still record any network requests from wasm

Re: Hello wasm-pack

#124

Post by eridius »

darepublic wrote: post #123
eridius wrote: post #71

Earlier quoted context omitted.

Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.

Wouldn't the network tab still record any network requests from wasm

I would assume so, but if the request is encrypted you wouldn't know what's in it.

Re: Hello wasm-pack

#125

Post by ridiculous_fish »

rickycook wrote: post #111
ridiculous_fish wrote: post #97

Earlier quoted context omitted.

Can you speculate on what these APIs will look like? JS is well suited for dealing with cross-browser incompatibilities because of its reflection support. That is much harder to build in a low-level target like WASM. COM is an example of what we might get, and that is not a pleasant prospect.

plenty of typed languages have reflection. i don’t see how this changes anything?

WASM is not a typed language. It is a language-agnostic compilation target.

So what would a DOM API exposed to WASM look like? COM is the only example that comes to mind.

Re: Hello wasm-pack

#126

Post by [deleted] »

arcatek wrote: post #98
ridiculous_fish wrote: post #95

In its wasm-rewrite, the source-map module acquired a destructor that must be manually invoked by its clients [1]. This makes the API much worse. Is this typical of JS APIs that use wasm? 1: https://github.com/mozilla/source-map#sourcemapconsumerproto...

Yes, the gc isn't exposed yet, so neither JS nor wasm are notified when an object goes out of scope (which would allow to reclaim the memory on the wasm side). It's on the roadmap, so it should eventually come.

[deleted]

Re: Hello wasm-pack

#127

Post by steveklabnik »

ridiculous_fish wrote: post #125
rickycook wrote: post #111

Earlier quoted context omitted.

plenty of typed languages have reflection. i don’t see how this changes anything?

WASM is not a typed language. It is a language-agnostic compilation target. So what would a DOM API exposed to WASM look like? COM is the only example that comes to mind.

> WASM is not a typed language. It is a language-agnostic compilation target.

These two things aren't contradictory. wasm is typed.

Re: Hello wasm-pack

#128

Post by fulafel »

eridius wrote: post #71
mpolichette wrote: post #18

I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect. https://hackernoon.com/im-harvesting-credit-card-numbers-and...

Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.

Maybe the code wraps querySelector and getAttribute for wasm, or similar. Or maybe its underhanded code, designed to do something different than it seems to.

Re: Hello wasm-pack

#129

Post by abritinthebay »

hinkley wrote: post #99
abritinthebay wrote: post #59

Earlier quoted context omitted.

It's absolutely a possibility but the problem is one of speed . DOM interop is one of the things that slows down JS so much and requires a lot of flexibility. Adding it to WASM will not be the amazing experience many think it will be.

I don't know about others but I'm not expecting it to be an amazing experience. It's more that I expect not having DOM interop to be an amazingly boring experience. Maybe Rust could be good for Web Workers but it'll be far more interesting when I can use it for interactions. The overhead problem you mention reminds me a little of the false intuition that people have about databases. I've worked on a couple projects w…

Good illustration of that issue.

I don’t know if I agree it’ll be less interesting- but it will have narrower applications. They’ll be more self contained - data and processing related - rather than driving the UI... but I don’t know if I’d call that not interesting.

I mean... imagine a WASM game engine where the modules/plugins can be any language as long as the compile target is WASM and they follow the right API... with JS/DOM just doing the DOM part (canvas or webgl I guess).

Sounds pretty powerful and fun.

Re: Hello wasm-pack

#130

Post by titzer »

girvo wrote: post #118
titzer wrote: post #78

Earlier quoted context omitted.

The cost is more than a JS->JS call, but not drastically so. Every argument must be converted from a number to an int32/float32/float64, which for SMI values is a single branch, for heap numbers a branch and a load. For other JS values, a ValueOf() operation on the JS value. V8 generates little wrappers for these, with inline conversions. It does not currently inline the little wrapper functions, nor use ICs for the…

For v8, doesn’t a try/catch block defeat inlining? It used to, but that was a long time ago.

No, not with TurboFan (since Q2 2017).
Post reply on HN