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

191–200 of 287 posts

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

#191

Post by flohofwoe »

nineteen999 wrote: post #156
mananaysiempre wrote: post #49

Earlier quoted context omitted.

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is th…

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "wor…

At least the 'web' part makes more sense than the 'assembly' part ;)

WASM was designed as a successor to asm.js, and asm.js was purely a web thing. While non-web-platforms were considered as a potential use case (in the sense of "using WASM outside the web should be possible", it wasn't clear at the time what the successful usages outside browsers would even look like).

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

#192

Post by laughinghan »

mananaysiempre wrote: post #49
eqrion wrote: post #15

Earlier quoted context omitted.

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more porta…

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is th…

You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly?

Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?

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

#193

Post by neonstatic »

leptons wrote: post #163
mananaysiempre wrote: post #9

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…

I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps. Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions,…

I for one am thankful to them for it. I think we need a return to the real native. The JS/Web-slop has gone too far.

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

#194

Post by flohofwoe »

afiori wrote: post #175
nineteen999 wrote: post #156

Earlier quoted context omitted.

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "wor…

The web part is the security model and the tradeoffs between security and performance. PNaCL was in browsers but not "web" for this reason. Like the assembly part means low-level and meant as a compilation target, not CPU instructions. So websssembly is an assembly language for the web, like webgl is opengl for the web and webgpu are gpu APIs for the web. And behold none of those can access DOM APIs

> So webassembly is an assembly language for the web.

But is isn't, at most WAT is (the WASM text format). WASM itself is a bytecode format. Nobody calls CPU machine code 'assembly' (nitpicking, I know, but the 'web' part of the name makes a lot more sense than the 'assembly' part).

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

#195

Post by flohofwoe »

bfivyvysj wrote: post #165
nineteen999 wrote: post #156

Earlier quoted context omitted.

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "wor…

Web assembly has never had anything to do with the web. At least that's been my experience whenever I find it in production.

This is retconning the history of WASM. While WASM was designed to be also be usable outside browsers, nobody could really predict at the time what this usage would look like exactly.

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

#196

Post by flohofwoe »

hmry wrote: post #190
flohofwoe wrote: post #188

Earlier quoted context omitted.

The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into browsers is overkill for that (and everything else belongs into the toolchains without touching the browser guts).

> The entire article boils down to one specific problem: string marshalling overhead No, I don't think so at all. 80% of the article is about other problems (JS bindings are complicated to generate and a leaky abstraction, additional tools beyond the compiler are required, compiler authors don't want to deal with them, they increase the friction for getting started, they're hard to debug, ...)

...all those problems should be fixed in the toolchains, not in the browser.

Emscripten exists, DWARF debugging support exists and works (I can step from C/C++ code into JS code and back with the WASM DWARF debugging extension for VSCode), other language ecosystems just need to catch up.

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

#197

Post by hardwaresofton »

flohofwoe wrote: post #179
hardwaresofton wrote: post #132

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly. With regards to the JS ecosystem specifically there are 3 projects to know: https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodeallia…

Get your blatant component model propaganda outta here ;) (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)

> Get your blatant component model propaganda outta here ;)

It's perfectly good content, sir!

> (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)

WebAssembly absolutely works fine without the component model, and I'd argue it's much better with the component model.

Here's my simple pitch.

world before component model:

    > be me
    > build a webassembly core module
    > give it to someone
    > they ask what imports it needs
    > they ask how to run it
    > they ask how to provide high level types to it
world after component model:

    > be me
    > write an IDL (WIT[0]) interface which specifies what the component should do
    > write the webassembly component
WebAssembly gives us an incredible tool -- a new compilation target that is secure, performant and extensible. We could crudely liken this to RISCV. In $CURRENT_YEAR it doesn't make sense to stop at the RISCV layer and then let everyone create their own standards and chaos in 50 directions on what the 1/2/3 step higher abstractions should be.

Emscripten carried the torch (and still does great work of course) in building this layer that people could build on top of, but it didn't go far enough. Tools like wasm_bindgen in Rust work great but lack cross-platform usage.

The Component Model is absolutely the future of WebAssembly. Maybe not the future of WebAssembly core, but if you want to be productive and do increasingly interesting things with WebAssembly, the Component Model is the standards-backed, community-driven, cross-platform, ambitious way to do things with WebAssembly.

To be incredibly blunt, the failure of other attempts to centralize community, effort, and bring people along to build a shared thing that is just low cost enough that everyone can build on top is impressive. Nothing against other efforts, but I just can't find any similar efforts that others have standardized on in any meaningful way.

We're talking about a (partially already here) world where every popular programming language just outputs to WebAssembly natively and computers on every popular architecture/platform have an easy time running those binaries and libraries? If that's not the future, paint me a different one/show me movement in that direction -- genuinely would love to see what I'm missing!

And in all of this, the Component Model is optional -- if you don't like it, don't use it. If WebAssembly core works for you, you are absolutely free to build! wasm32-unknown-unknown is right there, waiting for you to target it (in Rust at least).

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

#198

Post by hardwaresofton »

pjmlp wrote: post #181
hardwaresofton wrote: post #132

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly. With regards to the JS ecosystem specifically there are 3 projects to know: https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodeallia…

Hello COM, CORBA, RMI, Jini, .NET Remoting, Tcl Agents,..., that is basically what it is.

Very reductive :) there are flavors and hints of all these previous technologies /paradigms in WebAssembly + Component Model today, because only fools would attempt to build something without considering relevant prior art.

Won't bother trying going through differences/how-this-is-not-that but I'll say this: This time, it's slightly better, just like every time before.

I'd even go so far as to say this iteration is much better than what came before, and the speed of adoption by multiple language toolchains, platforms, operating systems, browsers proves that.

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

#199

Post by flohofwoe »

laughinghan wrote: post #192
mananaysiempre wrote: post #49

Earlier quoted context omitted.

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is th…

You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly? Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?

> but I don’t understand how #2 cross-lang interop could ever have been optional

This problem hasn't been solved outside the web either (at least not to the satisfaction of Rust fanboys who expect that they can tunnel their high level stdlib types directly to other languages - while conveniently ignoring that other languages have completely different semantics and very little overlap with the Rust stdlib).

At the core, the component model is basically an attempt to tunnel high level types to other languages, but with a strictly Rust-centric view of the world (the selection of 'primitive types' is essentially a random collection of Rust stdlib types).

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

#200

Post by flohofwoe »

leptons wrote: post #163
mananaysiempre wrote: post #9

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time…

I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps. Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions,…

This is a nice conspiracy theory but doesn't match facts like Safari implementing the WebGPU standard at a faster pace than Firefox. Safari might not be great in some areas, but their WASM/WebGPU/WebAudio support is in pretty good shape.
Post reply on HN