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

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

81–90 of 251 posts

Re: Pay attention to WebAssembly

#81

Post by mdasen »

fancyfredbot wrote: post #5

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

I think what makes thing succeed or not can be subtle (and therefore it's easy to disagree with). Ultimately, I think WASM will succeed because it's a uniting force among communities. Rust people are behind it, Microsoft and C#/.NET are behind it, people in the Go, Python, and other communities are behind it, and the browser vendors are behind it.

Java applets were things that were slow to load and didn't interface well with the rest of the web. People can talk about how you could technically connect things until they're blue in the face, but Java didn't provide a good experience with HTML. It was its own thing just like Adobe Flash.

I think that comparison is important: Java applets and Adobe Flash were these separate non-HTML entities that felt proprietary and didn't play nicely with others. Maybe something might be open-source, but Java applets felt like they were trying to usurp the web. JavaScript augments the web rather than usurping it - and WASM similarly fills that role.

I think that WASM will succeed where others haven't because it has been designed by the parties you need to get on board to make it succeed. Java wanted to create its own little world against the wishes of the vast majority of developers and users. Flash created its own little world against the wishes of most developers (though most users didn't mind). WASM feels like a neutral target that most of the community can get behind.

While WASM might not be perfect or anything, it does seem to unite a lot of different communities. It doesn't feel like Sun is coming along and imposing Java applets on everyone so that they can better sell Java to enterprises. It doesn't feel like Adobe trying to lock developers into expensive Flash tools. It doesn't feel like Microsoft saying, "Silverlight is our Flash! You should use that!" It's something that engineers from lots of different communities are supportive of and that works with the web rather than trying to usurp it.

Re: Pay attention to WebAssembly

#83

Post by SquibblesRedux »

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

Re: Pay attention to WebAssembly

#84

Post by jackothy »

astlouis44 wrote: post #77
hsheth2 wrote: post #75

Earlier quoted context omitted.

Thanks for the correction - I'll update my post shortly.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

Some advantages that Steam will still have:

1. Steam provides a system for user accounts and profiles

2. Steam handles payment securely for both buyers and sellers

3. Steam handles social networks/friend list/multiplayer

4. Steam allows you to have all your games in one place

5. Steam is a platform for reviews

6. Steam has its own internal economy/marketplace

Re: Pay attention to WebAssembly

#85

Post by astlouis44 »

jackothy wrote: post #84
astlouis44 wrote: post #77

Earlier quoted context omitted.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

Some advantages that Steam will still have: 1. Steam provides a system for user accounts and profiles 2. Steam handles payment securely for both buyers and sellers 3. Steam handles social networks/friend list/multiplayer 4. Steam allows you to have all your games in one place 5. Steam is a platform for reviews 6. Steam has its own internal economy/marketplace

What’s your point? All of that can be done on the web, besides it isn’t really targeting the Steam audience at the end of the day. Think the mobile audience, but on the web. You can do a Sims or PUBG in HTML5 today, and all that’s required is a hyperlink to share it with others. Same strategy that made Wordle go viral and get acquired today for over $1M.

Re: Pay attention to WebAssembly

#86

Post by zamadatix »

maga wrote: post #64
chrismorgan wrote: post #57

Earlier quoted context omitted.

Yeah, that repository is measuring performance of a WASM/Node.js hybrid, and not straight WASM. Interoperability costs can certainly dominate in such cases, where straight WASM can bypass much of the cost. Such a hybrid is what you want to measure often, but certainly not always, and a large part of what this article is talking about is the potential of pure WASM unshackled by Node.js.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

If you look at the success examples of 1Password or Skia they do a lot of compute based on little interaction (not no interaction). "Shackled" wasm occurs when doing things like running a string validation function as a user inputs keys into an input box, when you're constantly going between JS and WASM just to do a little work each time. It's not "I passed the data from JS and therefore it will always be slow now". In short it's not "replace any JS with WASM" it's "replace JS that isn't going to complete quickly with WASM" which is exactly the JS you should want to replace, not the stuff already running too fast to notice.

PSPDFKit is another example that added WASM to great success regarding rendering and searching. And uBlock Origin as well with its massive rule lists.

Re: Pay attention to WebAssembly

#87

Post by chrismorgan »

maga wrote: post #64
chrismorgan wrote: post #57

Earlier quoted context omitted.

Yeah, that repository is measuring performance of a WASM/Node.js hybrid, and not straight WASM. Interoperability costs can certainly dominate in such cases, where straight WASM can bypass much of the cost. Such a hybrid is what you want to measure often, but certainly not always, and a large part of what this article is talking about is the potential of pure WASM unshackled by Node.js.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost.

But even inside something like Node.js or the browser, most of these sorts of benchmark attempts are of converting only small parts of a system, so that message passing or format shifting ends up a comparatively large fraction of the work being done. If you migrate as much as possible into WASM and treat JS as the foreign side rather than WASM, you will tend to find that there’s much less serialisation/deserialisation overhead in the performance-sensitive parts, because the data they needed was on the WASM side from the start, rather than having to be copied in from the JS side. (This is, of course, a simplifying generalisation.) A somewhat more conservative strategy is to still treat JS as the native side as WASM as foreign, but expand the WASM as far as necessary to reach a point where very little data interchange will be needed. What that is may vary enormously, and such a boundary doesn’t always exist.

Re: Pay attention to WebAssembly

#88

Post by enos_feedler »

AnIdiotOnTheNet wrote: post #79
enos_feedler wrote: post #73

Earlier quoted context omitted.

Even if it's weird and designed by committee, at least we have agreement with all browsers. IMO, WebAssembly has got over the biggest hurdle: agreement in a format to feed an abstract processor to program it to do math. Nothing more, nothing less. In the web ecosystem, the most powerful thing right now is agreement. The design might be ugly or weird, but it works and it's done. Lets build on top of it.

Frankly, fuck the web. It's a warzone where Google throws its weight around to enhance the ability of advertisers to make our lives terrible. I was more interested in WASM as a universal VM for all platforms, but it doesn't fit nearly as well for that as it could because of some of the strange decisions this web-focused committee made. At least Java was also designed to run on not-the-web.

Yes, I am as well. But anything built on top of wasm to run everywhere should probably at least operate well inside a browser environment. Almost as an incubation environment for something bigger. The browser platform is too big to ignore. We rise up from Chrome, Firefox, Safari etc!!! Here and now!!! We Rise!

Re: Pay attention to WebAssembly

#89

Post by Findecanor »

ashvardanian wrote: post #65

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

There is a fixed-width SIMD extension though. It conforms to a common subset of instructions with similar semantics in SSE/AVX and the Neons.

Re: Pay attention to WebAssembly

#90

Post by duskwuff »

ashvardanian wrote: post #65

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

> [WASM is] still painfully slow compared to AVX or Neon enabled assembly.

There's an open proposal to add SIMD intrinsics to WASM.

https://github.com/WebAssembly/proposals/issues/1

Post reply on HN