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

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

Post reply on HN
Print view View original

71–80 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#71

Post by embedding-shape »

observationist wrote: post #65
Retr0id wrote: post #61

Earlier quoted context omitted.

What makes WASM execution riskier than JS?

Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.

> Novelty - JS has had more time and effort spent in hardening it

Taking this argument to its extreme, does this mean that introducing new technology always decreases technology? Because even if the technology would be more secure, just the fact that it's new makes it less secure in your mind, so then the only favorable move is to never adopt anything new?

Supposedly you have to be aware of some inherent weakness in WASM to feel like it isn't worth introducing, otherwise shouldn't we try to adopt more safe and secure technologies?

Re: Making WebAssembly a first-class language on the Web

#72

Post by flohofwoe »

glenstein wrote: post #53
flohofwoe wrote: post #6

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

With Google now pushing developer certification, Android and iOS practically being mandatory for certain basic functions like accessing your bank or certain government services, Webassembly would make web apps first class citizens that aren't subject to mobile operating system lockdown. Being able to complete on efficiency with native apps is an incredible example of purposeful vision driving a significant standard,…

FWIW my home computer emulators [1] already run at about the same performance (give or take 5..10% depending on CPU type) in WASM versus their natively compiled counterparts.

Performance is already as good as it gets for "raw" WASM, the proposed component model integration will only help when trying to use the DOM API from WASM. But I think there must be less complex solutions to accelerate this specific use case.

[1] https://floooh.github.io/tiny8bit/

Re: Making WebAssembly a first-class language on the Web

#73

Post by JoshTriplett »

traderj0e wrote: post #64
thefounder wrote: post #20

This is the right direction. Another important bit I think it’s the GC integration. Many languages such Go, C# don’t do well on wasm due the GC. They have to ship a GC as well due the lack of various GC features(I.e interior pointers)

Probably needs to be fixed by bundling runtimes for things like Go, or bringing back cross-website caching in some secure way if that's possible

That's an orthogonal problem. First it needs to be possible and straightforward to write GCed languages in the sandbox. Second, GCed languages need to be willing to fit with the web/WASM GC model, which may not exactly match their own GC and which won't use their own GC. And after that, languages with runtimes could start trying to figure out how they might reduce the overhead of having a runtime.

Re: Making WebAssembly a first-class language on the Web

#74

Post by JoshTriplett »

phickey wrote: post #37
csmantle wrote: post #28

Another important aspect is that, without an external library like `wabt`, I can't just open Notepad, write some inline WASM/WAT in HTML and preview it in a browser, in the same way that HTML+CSS+JS works. Having to obtain a full working toolchain is not very friendly for quick prototyping and demonstrative needs.

WebAssembly is a compiler target, not a human-authored language. There is exactly one audience of people for writing wat by hand: spec and tutorial authors and readers. Anyone actually developing an application they want to use will use a compiler to produce WebAssembly. Prove me wrong and write Roller Coaster Tycoon in raw wasm if you want, but having written and maintained wasm specs and toolchains for nearly a dec…

There is exactly one case where I'd like to write "raw wat" (and for that matter "raw wasm bytecode"): I'd love to do something like the "bootstrappable builds" project for wasm, starting with a simple wat-to-bytecode parser/translator written in raw bytecode, then some tools wirtten in raw wat for bootstrapping into other languages. :)

Re: Making WebAssembly a first-class language on the Web

#75

Post by kccqzy »

observationist wrote: post #65
Retr0id wrote: post #61

Earlier quoted context omitted.

What makes WASM execution riskier than JS?

Novelty - JS has had more time and effort spent in hardening it, across the browsers, WASM isn't as thoroughly battle-tested, so there will be novel attacks and exploits.

There is very significant overlap between browsers’ implementation of JS and WASM. For example in V8, the TurboFan compiler works for both JS and WASM. Compilation aside, all the sandboxing work done on JS apply to WASM too. This isn’t NaCl.

Re: Making WebAssembly a first-class language on the Web

#76

Post by throwaway12pol »

Retr0id wrote: post #63
Tepix wrote: post #54

WASM with DOM support will be great. Unfortunately it will also be great for obfuscation and malware.

You can already compile malware to obfuscated asm.js. If anything, WASM blobs are easier to reverse engineer than obfuscated JS - good luck writing a ghidra plugin for JS source.

What about obfuscated WASM blobs? At least obfuscated JS is still basically source code being interpreted, with WASM we will be running proprietary obfuscated binaries in the browser.

Re: Making WebAssembly a first-class language on the Web

#77

Post by koenschipper »

This article perfectly captures the frustration of the "WebAssembly wall." Writing and maintaining the JS glue code—or relying on opaque generation tools—feels like a massive step backward when you just want to ship a performant module.

The 45% overhead reduction in the Dodrio experiment by skipping the JS glue is massive. But I'm curious about the memory management implications of the WebAssembly Component Model when interacting directly with Web APIs like the DOM.

If a Wasm Component bypasses JS entirely to manipulate the DOM, how does the garbage collection boundary work? Does the Component Model rely on the recently added Wasm GC proposal to keep DOM references alive, or does it still implicitly trigger the JS engine's garbage collector under the hood?

Really excited to see this standardize so we can finally treat Wasm as a true first-class citizen.

Re: Making WebAssembly a first-class language on the Web

#78

Post by JoshTriplett »

flohofwoe wrote: post #6

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

> just to get 2x faster string marshalling

That is a useful benefit, not the only benefit. I think the biggest benefit is not needing glue, which means languages don't need to agree on any common set of JS glue, they can just directly talk DOM.

Re: Making WebAssembly a first-class language on the Web

#79

Post by flohofwoe »

patchnull wrote: post #36

[flagged]

> but the end state where you import a browser API like any other library in your language is genuinely simpler than the current JS FFI dance.

Tbf, Emscripten has solved this problem long ago - I don't quite understand what's the problem for other language ecosystems.

The JS shim is still there, but you don't need to deal with it, you just include a C header and "link with a library".

Some of the Emscripten-specific C APIs are also much saner than their web counterparts, which is an important aspect that would be lost with an automatic binding approach. And EM_JS (e.g. directly embedding JS code into C/C++ files) is just pure bliss, because it allows to easily write 'non-standard' binding layers that go beyond a simple 1:1 mapping.

Those features won't go away of course, I just feel like the work could be spent on solutions that provide more 'bang for the buck' (yeah, I've never been a fan of the component model to begin with).

Re: Making WebAssembly a first-class language on the Web

#80

Post by feznyng »

glenstein wrote: post #53
flohofwoe wrote: post #6

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

With Google now pushing developer certification, Android and iOS practically being mandatory for certain basic functions like accessing your bank or certain government services, Webassembly would make web apps first class citizens that aren't subject to mobile operating system lockdown. Being able to complete on efficiency with native apps is an incredible example of purposeful vision driving a significant standard,…

How does WASM solve the platform lockdown problem? That WASM will run in a third-party app that is subject to those restrictions. The system interface exposed within that runtime is still going to be limited in the same way a native app can't get real access to the filesystem, etc.
Post reply on HN