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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 207 posts

Re: WebAssembly’s post-MVP future

#31

Post by username223 »

fabian2k wrote: post #16

Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.

> Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript?

I may be out of date here, but IME neither JavaScript nor WASM is any good for actual "number crunching" (i.e. statistical or scientific code). For that, you want at least a compiler/language that uses the latest SIMD instructions and lets you choose 32- or 64-bit floats. Better still, you want one that automatically parallelizes loops (you may need to align your data), gives you cheap GPU access, and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.

Modern JS engines are pretty good at speeding up the weirdness that is JS, so maybe WASM will only have small benefits, but using either for numerical work would be making your life unnecessarily hard.

Re: WebAssembly’s post-MVP future

#32

Post by marcosdumay »

kodablah wrote: post #25
jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

The difference is being able to serve some WASM script that interacts with your page without having to send and entire glibc equivalent.

In practice, that means having an standard library on browsers that you can call in a standard idiom.

Re: WebAssembly’s post-MVP future

#33

Post by kodablah »

jdc wrote: post #27
kodablah wrote: post #25

Earlier quoted context omitted.

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

Performance

One might expect that never leaving the WASM context and interoperating with browser APIs, even if defined in JS terms, would not incur JS penalties. Granted it may affect JS argument validation. But this requires representation of those types. For example, if the DOM API allows searching for a selector which is a string, how do you build that string in WASM and how do you pass it? You'd use host refs anyways I would guess, essentially creating a new host "string" which is meaningfully equivalent to creating a JS string.

Re: WebAssembly’s post-MVP future

#34

Post by marcosdumay »

goatlover wrote: post #19
eksemplar wrote: post #14

Earlier quoted context omitted.

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just yo…

> Wasm isn't really for pretty apps you can quickly make in Vue.

Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

Re: WebAssembly’s post-MVP future

#35

Post by tachyonbeam »

skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

The biggest weakness of WASM IMO is that it doesn't have its own standard library. It relies on the HTML DOM. This is an awkward, overcomplicated API that tends to differ between browsers, and worst of all, changes all the time. Because of this, WASM will likely remain a second-class citizen in the browser. It will also keep suffering of the problem of code constantly breaking when the DOM changes.

Re: WebAssembly’s post-MVP future

#36

Post by TomMarius »

kodablah wrote: post #2

Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…

https://github.com/CommonWA/cwa-spec

Re: WebAssembly’s post-MVP future

#37

Post by maga »

fabian2k wrote: post #16

Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.

I have done some benchmarking comparing JS, WASM, and native C++ addon performance in Node.js: https://github.com/zandaqo/iswasmfast

From the look of it, in Node.js, WASM suffers less data exchange overhead while been decently close to performance of the native addons.

Re: WebAssembly’s post-MVP future

#38

Post by Crespyl »

dbielik wrote: post #11

The visualizations in this article are excellent!

I believe Lin Clark is the artist, she has a whole series called "Code Cartoons" where she explains various (usually web related) technical systems like WebRender in similarly excellent style.

[0] https://code-cartoons.com/

Re: WebAssembly’s post-MVP future

#39

Post by sk1pper »

msoad wrote: post #20

I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion

How does this not end up as Flash reincarnated though?

Re: WebAssembly’s post-MVP future

#40

Post by nine_k »

msoad wrote: post #20

I used to think without DOM web assembly is uselsess then I saw how Figma made their UI super fast rendering to a canvas and was convinced that hopefully WS will be the reason DOM apis go out of fashion

Displaying is the easier part. Taking input would be trickier.
Post reply on HN