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

91–100 of 160 posts

Re: Hello wasm-pack

#91

Post by themihai »

steveklabnik wrote: post #85
skybrian wrote: post #76

Earlier quoted context omitted.

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…

>> 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 would compile to WASM(along with DOM/webAPI access)? The ecosystem may be a reason but that's only a matter of time(i.e. 1 -2 years).

Re: Hello wasm-pack

#92

Post by steveklabnik »

themihai wrote: post #91
steveklabnik wrote: post #85

Earlier quoted context omitted.

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…

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

Re: Hello wasm-pack

#93

Post by mpolichette »

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.

Thats neat, cool, given that, we are at least only as susceptible as we were before.

Re: Hello wasm-pack

#94

Post by IshKebab »

austincheney wrote: post #79
IshKebab wrote: post #73

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

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.

Re: Hello wasm-pack

#96

Post by austincheney »

IshKebab wrote: post #94
austincheney wrote: post #79

Earlier quoted context omitted.

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

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 plans with active code in development to implement WASM as a JavaScript replacement, at least to my knowledge.

Re: Hello wasm-pack

#97

Post by ridiculous_fish »

IshKebab wrote: post #94
austincheney wrote: post #79

Earlier quoted context omitted.

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

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.

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.

Re: Hello wasm-pack

#98

Post by arcatek »

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.

Re: Hello wasm-pack

#99

Post by hinkley »

abritinthebay wrote: post #59
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?

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 where people were surprised that as the data set grew (either more customers, or accumulated customer activity), operations like INSERT and UPDATE got slower and slower, even without new functionality getting in the way. Everyone expects SELECT to get slower, but INSERTs seem to catch them off guard.

Every INSERT or UPDATE has to update the indexes. And when you quadruple the data, the update time for each index doubles. At first the cost of the insert is in the noise floor. It's swamped by the communication and transaction overhead. But after a handful of doublings it becomes detectable. A few more and it becomes noticeable. After a few more it becomes a problem, and if you haven't already changed your product roadmap, you do now.

To make a web page fast, you have to correlate the DOM with the CSS and the viewport. Adding more data isn't free.

Re: Hello wasm-pack

#100

Post by bzbarsky »

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.

You can read the JS code.

If it's trying to be sneaky, you _cannot_ understand it, in general. If you think you can, that is false confidence that is best gotten rid of.

Post reply on HN