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

31–40 of 287 posts

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

#31

Post by perfmode »

eqrion wrote: post #10
pizlonator wrote: post #5

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in…

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.…

There's something real in the impedance mismatch argument that I think the replies here are too quick to dismiss. The browser's programming model is fundamentally about a graph of objects with identity, managed by a GC, mutated through a rich API surface. Linear memory is genuinely a poor match for that, and the history of FFI across mismatched memory models (JNI, ctypes, etc.) tells us this kind of boundary is where bugs and performance problems tend to concentrate. You're right to point at that.

Where I think the argument goes wrong is in treating "most websites don't use WASM" as evidence that WASM is a bad fit for the web. Most websites also don't use WebGL, WebAudio, or SharedArrayBuffer. The web isn't one thing. There's a huge population of sites that are essentially documents with some interactivity, and JS is obviously correct for those. Then there's a smaller but economically significant set of applications (Figma, Google Earth, Photoshop, game engines) where WASM is already the only viable path because JS can't get close on compute performance.

The component model proposal isn't trying to replace JS for the document-web. It's trying to lower the cost of the glue layer for that second category of application, where today you end up maintaining a parallel JS shim that does nothing but shuttle data across the boundary. Whether the component model is the right design for that is a fair question. But "JS is the right abstraction" and "WASM is the wrong abstraction" aren't really in tension, because they're serving different parts of the same platform.

The analogy I'd reach for is GPU compute. Nobody argues that shaders should replace CPU code for most application logic, but that doesn't make the GPU a "dud" or a second-class citizen. It means the platform has two execution models optimized for different workloads, and the interesting engineering problem is making the boundary between them less painful.

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

#32

Post by eqrion »

pizlonator wrote: post #12
eqrion wrote: post #10

Earlier quoted context omitted.

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.…

> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…

> If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside

Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements.

> Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load. > The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it.

I don't think any Web API exposed directly to Wasm would have a single fixed ABI for that reason. We'd need to have the user request a type signature (through the import), and have the browser maximally try and satisfy the import using coercions that respect API evolution and compat. This is what Web IDL/JS does, and I don't see why we couldn't have that in Wasm too.

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

Wasm is not a dud on the web. Almost 6% of page loads use wasm [1]. It's used in a bunch of major applications and libraries.

[1] https://chromestatus.com/metrics/feature/timeline/popularity...

I still think we can do better though. Wasm is way too complicated to use today. So users of wasm today are experts who either (a) really need the performance or (b) really need cross platform code. So much that they're willing to put up with the rough edges.

And so far, most investment has been to improve the performance or bootstrap new languages. Which is great, but if the devex isn't improved, there won't be mass adoption.

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

#33

Post by phickey »

skybrian wrote: post #18

At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency: https://github.com/WebAssembly/component-model/blob/main/des...

Real programs, whether native JavaScript or in any other language that targets Wasm, have concurrency. Would you rather the component model exclude all concurrent programs, and fail to interact with concurrent JavaScript? The component model is meeting the web and programmers where they're at. Unless you're one of the few people implementing the low level bindings between components and guest or host languages, you don't have to ever read the CM spec or care about the minutae of how it gets implemented.

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

#34

Post by pizlonator »

swiftcoder wrote: post #30
pizlonator wrote: post #27

Earlier quoted context omitted.

Figma is one site. There are also a handful of other sites that use wasm. But most of the web does not use wasm. > Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve. I don't think they will succeed at solving the pain, for the reasons I have enumerated in this thread.

I mean, you are obviously entitely to your opinion, but folks have been solving this stuff the hard, glue-based way for ages now, and are using WASM wherever there is an advantage to do so. Getting rid of the glue layer and the associated performance problems can only accelerate those efforts

> I mean, you are obviously entitely to your opinion

I'm trying to explain to you why attempts to make wasm mainstream have failed so far, and are likely to continue to fail.

I'm not expressing an "opinion"; I'm give you the inside baseball as a browser engineer.

> Getting rid of the glue layer

I'm trying to elucidate why that glue layer is inherent, and why JS is the language that has ended up dominating web development, despite the fact that lots of "obviously better" languages have gone head to head with it (Java, Dart sort of, and now wasm).

Just like Java is a fantastic language anywhere but the web, wasm seems to be a fantastic sandboxing platform in lots of places other than the web. I'm not trying to troll you folks; I'm just sharing the insight of why wasm hasn't worked out so far in browsers and why that's likely to continue

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

#35

Post by eqrion »

skybrian wrote: post #18

At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency: https://github.com/WebAssembly/component-model/blob/main/des...

The concurrency part of the C-M is complicated (I think for inherent reasons), but won't be exposed to end users. It's basically defining an API that language toolchains can use to coordinate concurrency.

For end users, they should just see their language's native concurrency primitives (if any). So if you're running Go, it'll be go routines. JS, would use promises. Rust, would have Futures.

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

#37

Post by phickey »

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 decade, I will never write any wat outside of a spec or tutorial.

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

#39

Post by swiftcoder »

pizlonator wrote: post #34
swiftcoder wrote: post #30

Earlier quoted context omitted.

I mean, you are obviously entitely to your opinion, but folks have been solving this stuff the hard, glue-based way for ages now, and are using WASM wherever there is an advantage to do so. Getting rid of the glue layer and the associated performance problems can only accelerate those efforts

> I mean, you are obviously entitely to your opinion I'm trying to explain to you why attempts to make wasm mainstream have failed so far, and are likely to continue to fail. I'm not expressing an "opinion"; I'm give you the inside baseball as a browser engineer. > Getting rid of the glue layer I'm trying to elucidate why that glue layer is inherent, and why JS is the language that has ended up dominating web develop…

> why JS is the language that has ended up dominating web development

JS was dominating web development long before WASM gained steam. This isn't the same situation as "JS beating Java/ActivX for control of the web" (if I follow the thrust of your argument correctly).

WASM has had less than a decade of widespread browser support, terrible no-good DevEx for basically the whole time, and it's still steadily making it's way into more and more of the web.

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

#40

Post by haberman »

> Thankfully, there is the esm-integration proposal, which is already implemented in bundlers today and which we are actively implementing in Firefox.

From the code sample, it looks like this proposal also lets you load WASM code synchronously. If so, that would address one issue I've run into when trying to replace JS code with WASM: the ability to load and run code synchronously, during page load. Currently WASM code can only be loaded async.

Post reply on HN