Discussion

Hacks

mitchbob: Discussed 12 days ago (13 comments):https://news.ycombinator.com/item?id=47167944

tomhow: We've decided to give it another try as it didn't get much front page time or discussion.

flohofwoe: 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 mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).It would be nice to see some benchmarks for WebGL2 and WebGPU with a tens-of-thousands of draw calls.

mananaysiempre: 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.)Better late than never I guess.[1] https://github.com/WebAssembly/interface-types/commit/f8ba0d...[2] https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...[3] https://queue.acm.org/detail.cfm?id=3746174

eqrion: 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 portable.I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.

throwaway2027: Great to see it happening finally. Can we also get compute shaders with WebGL2 now? I don't want to move everything to WebGPU just for compute shaders and I don't know why they kept rejecting the proposals.

pizlonator: 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 objects. Each part of the web page is an object. JavaScript is object oriented.WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web.Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it.I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.

flohofwoe: That's just like your opinion man ;)(I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)

pizlonator: Then give me a counterargument instead of just saying that I'm wrong.My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.

flohofwoe: I created and maintain a couple of WASM projects and have not experienced the problems you describe:- https://floooh.github.io/tiny8bit/- https://floooh.github.io/sokol-webgpu/- https://floooh.github.io/visualz80remix/- https://floooh.github.io/doom-sokol/All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users.Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed. Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file.E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.

eqrion: I'm not sure I follow this.> WebAssembly is the wrong abstraction for running untrusted apps in a browserWebAssembly 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.> 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.There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.> Browser engines deal in objects. Each part of the web page is an object. JavaScript is object orientedThe first major language for WebAssembly was C++, which is object oriented.To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.

pizlonator: > 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 WebAssembly, you'd have an even harder time than exposing those APIs to JS, because:- You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data.- You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers.> There are dynamic languages, like JS/Python that can compile to wasm.If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM.If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside.> Also I don't see how dynamic typing is required to have API evolution and compt.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.> Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.We're talking about the browser, which is a particular platform. Not all platforms are the same.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.> The first major language for WebAssembly was C++, which is object oriented.But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes.> To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

pizlonator: The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.

flohofwoe: > why webassembly is not used by the overwhelming majority of websitesThis is such a bizarre take that I don't know whether it's just a trolling attempt or serious...Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two approaches live side by side, each with specific advantages and disadvantages, they are not competing with each other.

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

swiftcoder: > Then what's your excuse for why wasm, despite years of investment, is a dud on the web?It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on).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.

pizlonator: 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.

hexo: What about no.

pizlonator: > This is such a bizarre take that I don't know whether it's just a trolling attempt or serious...I'm being serious.> Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS?They mostly shouldn't. There are very few problems where wasm is better.If you want to understand why wasm is not better, see my other posts in this thread.

skybrian: 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...

phickey: 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.

eqrion: > If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upsideLanguage 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.

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.

bvisness: This is not strictly true; there are synchronous APIs for compiling Wasm (`new WebAssembly.Module()` and `new WebAssembly.Instance()`) and you can directly embed the bytecode in your source file using a typed array or base64-encoded string. Of course, this is not as pleasant as simply importing a module :)

swiftcoder: 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

pizlonator: > I mean, you are obviously entitely to your opinionI'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 layerI'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

swiftcoder: > why JS is the language that has ended up dominating web developmentJS 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.

pizlonator: WebAssembly has had extraordinary levels of investment from browser devs and the broader community.> terrible no-good DevEx for basically the whole timeI'm telling you why.> still steadily making it's way into more and more of the web.It is, but you can still browser the web without it just fine, despite so much investment and (judging by how HN reacts to it) overwhelming enthusiasm from devs

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

glenstein: 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, exactly the kind of thing I want for the future of the web and an example of why we need more stewards like Mozilla.

dbdr: If it "only" speeds up DOM access, that's massive in itself. DOM is obviously a crucial element when running inside a browser.

lich_king: The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy.And now that we're getting close to have the right design principles and mitigations in place and 0-days in JS engines are getting expensive and rare... we're set on ripping it all out and replacing it with a new and even riskier execution paradigm.I'm not mad, it's kind of beautiful.

ngrilly: We could finally write programs for the browser in any language that compiles to WebAssembly. And even mix and match multiple languages. It would be amazing.

saghm: That's a fairly arbitrary metric. The overwhelming majority of code running outside of the browser on my laptop isn't in Python, but it's hard to argue that's evidence of it being "doomed to being a second-class citizen on my desktop indefinitely".

patchnull: The 45% reduction in DOM operation time from removing JS glue is the number that should change how people think about this. WASM has been stuck in a chicken-and-egg loop for years: no DOM access meant the only viable use cases were compute-heavy workloads like codecs and crypto, which kept the ecosystem too small to justify better tooling, which kept adoption low. Direct web API binding through the component model breaks that loop because it finally makes WASM viable for ordinary web development, not just the hot-path optimization niche. The complexity concerns in this thread are valid but I think they are transitional. The WIT layer looks heavyweight now because the toolchains are immature, 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.

tcfhgj: > no DOM access meant the only viable use cases were compute-heavy workloads like codecs and crypto,no, it didn't mean that, because the overhead is not a deal breaker:1) you don't have to do the glue code (libs can do it for you) 2) there's overhead due to glue, but the overhead is so small that WASM web frameworks easily can compete with fast JS frameworks in DOM heavy scenarios.Source: Analysis of the creator of Leptos (a web framework based on WASM): https://www.youtube.com/watch?v=4KtotxNAwME

Retr0id: What makes WASM execution riskier than JS?

observationist: 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.

thefounder: 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)

traderj0e: 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

Retr0id: 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.

phickey: 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.

JoshTriplett: 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. :)

JoshTriplett: 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.

flohofwoe: 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/

embedding-shape: > Novelty - JS has had more time and effort spent in hardening itTaking 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?