11 ms·

Making WebAssembly a first-class language on the Web

• mitchbob 7mo ago
  Discussed 12 days ago (13 comments): https://news.ycombinator.com/item?id=47167944 https://news.ycombinator.com/item?id=47167944
  • tomhow 7mo ago
    We've decided to give it another try as it didn't get much front page time or discussion.
• swiftcoder 7mo ago
  Nice to see momentum here. Even outside of direct access to WebAPIs, having the ability to specify interfaces for WASM modules is a big deal, and unlocks all sort of cool options, like sandboxed WASM plugins for native apps...
• pizlonator 7mo ago
  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 7mo ago
    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 7mo ago
      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 7mo ago
        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/tiny8bit/ - https://floooh.github.io/sokol-webgpu/ https://floooh.github.io/sokol-webgpu/ - https://floooh.github.io/visualz80remix/ https://floooh.github.io/visualz80remix/ - https://floooh.github.io/doom-sokol/ 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 (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have one - unless you count integer and float types as type system"). 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.
        • pizlonator 7mo ago
          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 7mo ago
            > why webassembly is not used by the overwhelming majority of websites This 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 technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.
  • eqrion 7mo ago
    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. > 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 oriented The 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 7mo ago
      > 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?
  • saghm 7mo ago
    I'm not convinced JavaScript is a great abstraction for the browser as much as we've forced the web into a shape that fits JavaScript because of a lack of viable alternatives. I'd argue that the popularity of TypeScript implies that dynamic typing is not a universal ideal. Browser engines deal in objects because they're currently all built on top of JavaScript only; that doesn't demonstrate anything fundamental about the web that implies object oriented is the only reasonable representation. If it gets stuck as a second-class citizen like you're predicting, it sounds a lot more like it's due to inflexibility to consider alternatives than anything objectively better about JavaScript.
  • hrmtst93837 7mo ago
    [flagged]
  • hrmtst93837 7mo ago
    [flagged]
• flohofwoe 7mo ago
  It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 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 tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.
  • eqrion 7mo ago
    I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications. And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.
    • azakai 7mo ago
      > DOM performance is a big deal and bottleneck for a lot of applications What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production. > But we really shouldn't be requiring everyone to become an expert to benefit from wasm. If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug native applications. I agree tools could be a lot better here! But as I think you know, my position is that we can move faster and get better results on the tools side.
• mananaysiempre 7mo ago
  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/f8ba0d044e7846c29b7f05c73acaf5251a47a83d https://github.com/WebAssembly/interface-types/commit/f8ba0d... [2] https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... [3] https://queue.acm.org/detail.cfm?id=3746174 https://queue.acm.org/detail.cfm?id=3746174
  • eqrion 7mo ago
    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.
    • mananaysiempre 7mo ago
      > 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 the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Yes, another part of the problem, unrelated to the WIT story, seems to have been the abandonment of the idea that <script> could be something other than JavaScript and that the APIs should try to accomodate that, which had endured for a good while based on pure idealism. That sure would have come useful here when other languages became relevant again. (Now with the amputation of XSLT as the final straw, it is truly difficult to feel any sort of idealism from the browser side, even if in reality some of the developers likely retain it. Thank you for caring and persisting in this instance.)
• steve_adams_86 7mo ago
  The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved. The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM. The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet. The go example (https://component-model.bytecodealliance.org/language-support/building-a-simple-component/go.html https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get? I suppose I could sum up the concern as shifting complexity rather than eliminating it.
  • eqrion 7mo ago
    I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.
    • davexunit 7mo ago
      I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?
• throwaway2027 7mo ago
  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.
• skybrian 7mo ago
  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/design/mvp/CanonicalABI.md https://github.com/WebAssembly/component-model/blob/main/des...
  • phickey 7mo ago
    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.
    • skybrian 7mo ago
      I was looking there because the high-level documentation doesn't seem detailed enough to understand how it works. Maybe some intermediate-level explanations are needed?
  • eqrion 7mo ago
    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.
• thefounder 7mo ago
  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 7mo ago
    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
    • JoshTriplett 7mo ago
      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.
      • cogman10 7mo ago
        > Second, GCed languages need to be willing to fit with the web/WASM GC model I think most languages could pretty easily use WASM GC. The main issue comes around FFI. That's where things get nasty.
        • pjmlp 7mo ago
          WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement.
          • cogman10 7mo ago
            Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit harder since it'd only be for WASM.
• koolala 7mo ago
  Every new standard today doesn't care about being clean and simple to use. They all maximize the JS boilerplate needed to make a basic example work. Everything is designed today for 'engineers' and not 'authors' without any friendly default workflow. I'm glad they still care about this.
• hexo 7mo ago
  [flagged]
  • dang 7mo ago
    Could you please stop posting unsubstantive comments? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
• csmantle 7mo ago
  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.
  • phickey 7mo ago
    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 7mo ago
      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. :)
  • saghm 7mo ago
    The same limitation exists with "non-web" assembly. It turns out that having languages that compile to assembly makes a lot of sense for almost every real-world use case than writing it by hand.
• patchnull 7mo ago
  [flagged]
  • tcfhgj 7mo ago
    > 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 https://www.youtube.com/watch?v=4KtotxNAwME
  • embedding-shape 7mo ago
    > meant the only viable use cases were compute-heavy workloads like codecs and crypto And games, which the web is now a viable platform for a huge range of them, albeit not the top of the range, AAA and all that (yet?). Also some new graphical editors taking advantage of it, probably Figma being the most famous example so far.
  • flohofwoe 7mo ago
    > 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).
  • nikeee 7mo ago
    > the only viable use cases were compute-heavy workloads like codecs and crypto, I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated. Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.
• devwastaken 7mo ago
  [flagged]
• haberman 7mo ago
  > 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 7mo ago
    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 :)
• barelysapient 7mo ago
  Wow. We need this so bad.
• ngrilly 7mo ago
  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.
  • deleted 7mo ago
    [deleted]
• lich_king 7mo ago
  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.
  • Retr0id 7mo ago
    What makes WASM execution riskier than JS?
    • observationist 7mo ago
      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.
      • Retr0id 7mo ago
        On one hand, yes, new attack surface is new attack surface. But WASM has been in browsers for almost a decade now.
        • lich_king 7mo ago
          Without the bindings this talks about, so it really couldn't do nearly as much.
          • 0x457 7mo ago
            WASM has access to everything JS has via JS in the same sandbox that JS runs in. JS didn't magically become more "secure". Multiple things happened: - ActiveX and Flash got booted from browsers - Browsers got much better sandboxes Essentially limited what untrusted code can run and sandboxed that untrusted code. Before NaCl and PNaCl it was wild west in browsers. The same sandbox runs WASM. It even goes through the same runtime in every browser. It's no different from compiling language of your choice to subset of JavaScript (see asm.js).
• Tepix 7mo ago
  WASM with DOM support will be great. Unfortunately it will also be great for obfuscation and malware.
  • Retr0id 7mo ago
    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.
    • throwaway12pol 7mo ago
      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.
      • Retr0id 7mo ago
        I'd rather deal with an obfuscated WASM blob than obfuscated JS.
        • throwaway12pol 7mo ago
          Why is that? With obfuscated JS you can instantly create ASTs, easily patch and preview the results. We have codemodding tools for mass patching and analysis. With WASM, you can theoretically have a future anti-tamper corporation with a solution to actively obfuscate binaries and antagonize reverse engineers, like we have today with desktop binaries.
          • Retr0id 7mo ago
            ASTs are pretty useless once it's been through a control-flow flattening obfuscation pass. At the end of the day it's just one representation vs another, but there are a lot more existing tools for dealing with binary reverse engineering.
          • 7mo ago
• lasgawe 7mo ago
  Agree with the points. But when reading this, it seems much more complicated than using JavaScript on the web when developing realworld applications. However I think that will not be an issue because of AI.
• lasgawe 7mo ago
  Agree with the points. But when reading this, it seems much more complicated than using JavaScript on the web when developing real-world applications. However I think that will not be an issue because of AI.
• exabrial 7mo ago
  I'd really like to be able to run _any_ language in the browser. WASM is a great first step.
  • joshuaissac 7mo ago
    Internet Explorer used to support any language that Windows Script Host could run. By default, that was JScript and VBScript, but there were third-party engines for Python, Perl, Ruby, Lua, and many others. Possibly disabled now as they announced VBScript would be disabled in 2019.
    • tech234a 7mo ago
      Also Visual Basic: https://news.microsoft.com/source/1996/10/28/microsoft-introduces-visual-basic-5-0-control-creation-edition/ https://news.microsoft.com/source/1996/10/28/microsoft-intro...
      • joshuaissac 7mo ago
        That was something else entirely. Not for scripting but to write compiled ActiveX browser add-ons.
    • pjmlp 7mo ago
      Yes, we used the plugins from ActiveState on Tcl.
    • exabrial 7mo ago
      This is exactly what we need!
• koenschipper 7mo ago
  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.
  • hinkley 7mo ago
    I’m wondering if the recent improvements in sending objects through sendMessage in v8 and Bun change the math here enough to be good enough. SendMessage itself is frustratingly dumb. You have excessively bit fiddly or obnoxiously slow as your options. I think for data you absolutely know you’re sending over a port there should be an arena allocator so you can do single copy sends, versus whatever we have now (3 copy? Four?). It’s enough to frustrate use of worker threads for offloading things from the event loop. It’s an IPC wall, not a WASM wall. Instead of sending bytes you should transfer a page of memory, or several.
  • nneonneo 7mo ago
    Your comment - and your last two comments too - all sound very LLM-written. Using an LLM for commenting is explicitly against the site rules (https://news.ycombinator.com/newsguidelines.html#generated https://news.ycombinator.com/newsguidelines.html#generated).
  • thezipcreator 7mo ago
    webassembly components use a borrow checking model[1], so I assume that would be used to manage DOM components? I'm not exactly sure how this works when binding it to GC languages. [1] https://component-model.bytecodealliance.org/design/wit.html#resources https://component-model.bytecodealliance.org/design/wit.html...
• jjcm 7mo ago
  This is a great step, if only because it enforces more convention for the "right" way to do things by providing a simpler mechanism for this. WRT WebAssembly Components though, I do wish they'd have gone with a different name, as its definition becomes cloudy when Web Components exist, which have a very different purpose. Group naming for open source is unfortunately, very hard. Everyone has different usages of words and understanding of the wider terms being used, so this kind of overlap happens often. I'd be curious if this will get better with LLM overseers of specs, who have wider view of the overall ecosystem.
  • boomlinde 7mo ago
    What's there is already dead simple. The JS side and the WebAssembly module instance share a memory image and tables of imported and exported functions and variables. Everything else is left as an exercise to the programmer. It's hard to imagine a simpler, more conceptually straight-forward approach to it. An interface description language and component model at best makes some use cases more accessible at the expense of simplicity. Not that I necessarily think it's unwarranted. While I appreciate the simplicity of the current approach to interop because it gives you free reign and is easy to grasp, I think anyone who has spent some time rawdogging JS-WebAssembly integration has considered inventing their own WASM IDL analog. If that can be specified as part of the standard it can also be made quicker.
• shevy-java 7mo ago
  > Yet, it still feels like something is missing that’s holding WebAssembly back from wider adoption on the Web. > There are multiple reasons for this, but the core issue is that WebAssembly is a second-class language on the web It would be nice if WebAssembly would really succeed, but I have to be honest: I gave up thinking that it ever will. Too many things are unsolved here. HTML, CSS and JavaScript were a success story. WebAssembly is not; it is a niche thing and getting out of that niche is now super-hard.
• zb3 7mo ago
  No no no, wasm has shitty speed if you want to emulate something (it doesn't even support JIT), the problem is in its architecture (tons of restrictions like no self modifying code, no jumps).. this can't be fixed, we need something real, something like WebKVM.
  • titzer 7mo ago
    On the web you can dynamically create new Wasm modules and use JS APIs to load them, though there are ergonomic issues. There are per-module costs and systems like CheerpJ and CheerpX currently do batching of multiple functions into a module to mitigate the per-module costs. I've created a proposal to add a fine-grained JIT interface: https://github.com/webassembly/jit-interface https://github.com/webassembly/jit-interface It allows generating new code one function at a time and a robust way to control what the new code can access within the generating module.
• ventuss_ovo 7mo ago
  The phrase "first-class" matters here because most developers do not reject a platform over peak performance, they reject it over friction. If the happy path still requires language-specific glue, generated shims, and a mental model of two runtimes, then WebAssembly remains something you reach for only when the pain is already extreme. What would really change perception is not just better benchmarks, but making the boring path easy: compile with the normal toolchain, import a Web API naturally, and not have to become a part-time binding engineer to build an ordinary web app.
• ilaksh 7mo ago
  I love WebAssembly components and that's great progress. But I feel like everyone is missing a golden opportunity here to take apart the giant OS-sized web API and break some of it out into smaller standard or subscribable subsets that also don't try to mix information presentation and applications in a forced way. Example subsets: - (mainly textual) information sharing - media sharing - application sharing with, small standard interface like WASI 2 or better yet including some graphics - complex application sharing with networking Smaller subsets of the giant web API would make for a better security situation and most importantly make it feasible for small groups to build out "browser" alternatives for information sharing, media or application sharing. This is likely to not be pursued though because the extreme size of the web API (and CSS etc.) is one of the main things that protects browser monopolies. Even further, create a standard webassembly registry and maybe allow people to easily combine components without necessarily implementing full subsets. Do webassembly components track all of their dependencies? Will they assume some giant monolithic API like the DOM will be available? What you're doing is essentially creating a distributed operating system definition (which is what the web essentially is). It can be designed in such a way that people can create clients for it without implementing massive APIs themselves.
  • thezipcreator 7mo ago
    iirc webassembly components need to explicitly import anything they use, so it should be transparent which dependencies something has by just grepping its WIT for `import`
    • flohofwoe 7mo ago
      I wonder what a 'mixed model' would look like (e.g. is it even possible), e.g. an application which wants to call into component model APIs, but at the same time also needs to call into JS code which then accesses the same APIs. This hybrid model will definitely be needed for any non-trivial web application.
      • thezipcreator 7mo ago
        you can just expose javascript functionality as a component, if need be
• dana321 7mo ago
  This is a brilliant idea for webassembly, implementing the core browser features as libraries - they should do it. (though i do like the open code nature of the internet even if a lot of the javascript source code is unreadable and/or obfuscated)
• bikamonki 7mo ago
  Do programmers actually write in wasm or automatic tools port/compile other languages to wasm?
  • ivanjermakov 7mo ago
    Ratio of web developers writing wasm is even less than ratio of system developers writing asm.
  • kpcyrd 7mo ago
    It's mostly Rust compiled to wasm binaries. There's also TinyGo and you could use C/C++ as well, but those 3 are a lot less common as far as I can tell.
    • pjmlp 7mo ago
      And Blazor, however I am not a big fan of it, it feels like an escape path for WebForm developers, and I surely don't want to debug that kind of code again, MVC is much better approach.
  • mikestaas 7mo ago
    I wouldn't generally use hand coded WASM in production, but I've used it for educational purposes [1], and just because I'm perhaps a bit perverse [2][3] (3 includes some helper utilities in Common.ts). [1] https://exercism.org/profiles/mikestaas/solutions https://exercism.org/profiles/mikestaas/solutions [2] https://github.com/mikestaas/wasmfizzbuzz/blob/main/fizzbuzz.ts https://github.com/mikestaas/wasmfizzbuzz/blob/main/fizzbuzz... [3] https://github.com/mikestaas/walox/tree/main/src https://github.com/mikestaas/walox/tree/main/src
• hinkley 7mo ago
  Gretchen. Stop trying to make DOMless WASM happen. It’s not going to happen.
• r2vcap 7mo ago
  The strength—and also the weakness—lies in how WASM is consumed in the browser. During instantiation, JavaScript engines validate the module and reject it if it uses unsupported instructions or features. In practice, due to browser compatibility differences, WASM modules often need to be built in multiple variants, such as a baseline version, a SIMD version, a SIMD+threads version, and so on. This is a significant pain compared to native binaries, which can rely on runtime feature detection and dynamic dispatch.
• hardwaresofton 7mo ago
  If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ 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/bytecodealliance/StarlingMonkey https://github.com/bytecodealliance/ComponentizeJS https://github.com/bytecodealliance/ComponentizeJS https://github.com/bytecodealliance/jco https://github.com/bytecodealliance/jco The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come. One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are getting closer every week.
  • flohofwoe 7mo ago
    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)
    • hmry 7mo ago
      You're replying to a comment on an article about how WASM does not work fine in the browser
      • flohofwoe 7mo ago
        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).
        • hmry 7mo ago
• thisislife2 7mo ago
  This maybe an unpopular opinion, but I feel WebAssembly in the browser is the wrong direction - this vision to turn the browser into an OS so that we are then forced to rent every software through the "cloud" will screw all of us eventually. It is going to make the web less open. With HTML and Javascript (or even VBscript in the old IE), you could always look at the source. Good luck doing the same with WebAssembly. Soon websites will start bundling WebAssembly malwares and browsers will then also bundle an anti-virus (probably coded with WebAssembly) to counter it. Ofcourse, the anti-virus will need a "cloud service" so everything you do on the browser will be collected and sent "anonymously" ... good bye privacy.
  • qbane 7mo ago
    You can still obfuscate JS heavily and make a VM that executes also obfuscated code calling arbitrary browser APIs. At least In WASM everything is sandboxed so the attack surface is smaller.
• rishflab 7mo ago
  I don't understand the push to make the browser a tool for securely running general purpose applications. This is the job of the OS. We keep building layers on top of layers of abstraction instead of fixing or improving what we have. I think web apps are dead anyway and the browser is heading towards being a legacy software. The future is small ephemeral UIs generated on the fly by LLMs that have access to datasources. WASM is too late.
• patchnull 7mo ago
  [dead]
• andsoitis 7mo ago
  The blog post exemplifies the root of the problem IMHO. Which is to say, dancing around the core issue, which is direct DOM access as well as anything else JS has privileged access to.
• esprehn 7mo ago
  The web doesn't work without dynamic feature detection. I couldn't find anything in the component model about how this is expected to work. The DOM is not a static interface, it changes both across browsers based on implemention status and also based on features enabled on a per page load basis. The multi browser ecosystem also mainly works because of polyfills. It's not clear how to polyfill random methods on a WIT interface or how to detect at runtime which methods exist. OTOH the JS bridge layer we use today means you can load JS side polyfills and get wasm that's portable across browsers with no modifications. There's more to the ecosystem than just performance.
• dgudkov 7mo ago
  While WASM Components haven't arrived yet, what's the current best framework for JS/WASM glue?
• GianFabien 7mo ago
  I don't use WASM as a replacement for JS. I never have a need to manipulate DOM, etc from WASM. JS is perfectly fine and performant for those purposes. As I see it, WASM is used to augment the JS/WebAPI ecosystem. For example, when you need to do heavy bit manipulation, complex numerical processing. The round-trip JS->WASM->JS is an overhead. So the WASM modules should perform a substantial amount of processing to offset that inefficiency. I frequently find that V8 optimisations yield sufficient performance without needing to delve into WASM. IMHO if you want to write WebApps in Rust, you're holding it wrong.
  • thezipcreator 7mo ago
    I disagree. That's how WASM is now, and I guess that's fine, but that's not all it could be. I really think it would be awesome if you could write code for the web in your preferred programming language.
• boredatoms 7mo ago
  I hope one day we can use wasm without html, just pointing the url at the wasm file
• thezipcreator 7mo ago
  The WASM component model is really cool in that you can export basically anything as a component and use it in basically anything else that can compile to WASM and understand components. I would love something like this for native applications; I'm so tired having to wear C's skin every time I want to do bind together code written in different languages.
• notepad0x90 7mo ago
  I was just discussing/commenting on this a couple of weeks ago: https://news.ycombinator.com/item?id=47133223 https://news.ycombinator.com/item?id=47133223 Hear me out: Web APIs need to devolve into... APIs. DOM needs to devolve into a UI API. We have PWA's, File System APIs, USB APIs, peripheral device APIs, all the things a native webui client would be doing. Yes, it is "back to square one" , we already have websites masquerading as native apps via electron and tauri. On the other end you have a handful of tech companies dictating how our computing experience should be because they control browsers. WASM should be the bytecode format for executing untrusted code from the network and running a UI-capable application with controlled access to the system, that runs in a secure sandbox. This is java applets but better. You have the same issue on mobile where regular websites create apps, so they can be persistent and have access to things they shouldn't, and be all naughty. This happens because somehow we treat "native" differently than "web". it should all be restricted like web apps are, sandboxed tightly, but given access to resources like any electron app would (but not your entire file system, or entire anything, ever!) There shouldn't be any "installing" anything, perhaps bookmarking an app instead. I'm not saying let's do away with proper native apps, non-GUI apps still have a place, as do system services and extensions which are a whole other class of system applications. But your banking app isn't one of those, neither is a social media app, or a photo editor, a game, uber,etc.. all these can run in WASM, and WASM in turn gets native access to APIs similar to but not exactly web apis. I learned in that other comment thread that replicating the web DOM APIs for WASM is a foolish effort since it is all built with JS in mind. However, an HTML5 compatible DOM layer, that is distinct from DOM-manipulation layers, and has a low-level styling layer (not a best like CSS, but something CSS can be compiled into, or that WASM styling code would natively compile into). You will still need something to run the WASM like browsers do today, but here is the biggest value of my proposal: Unlike browsers, this would be heavily standardized, and as far as how your WASM renders and manipulates the DOM, that would be extremely consistent across WASM browsers, mainly because it would be so low-level there won't be any opinionated subjective interpretations between host apps. Unlike JS, there won't be any script runtime, unlike CSS, there is no styling engine. The responsibility of a beast like V8 is divided so that DOM, styling,security and API interactions are strongly defined in bytecode/ABI by the standard for the WASM host/browser, the actual UI of the app (tabs, themes, extensions,bookmarks, history,etc..) would not be different between WASM host/browsers, and of course the app's logic would be defined in whatever language, which will be compiled into WASM bytecode compatible with the aforementioned standard. This should result in consistent UI, fully networked apps with controlled resource access, that run ephemerally (caching as desired), storing persistent data as needed (no software updates per-app). It is a lot of effort but consider the state of computing, between mobile apps, things like flatpak, electron, tauri, "vendoring", PWA apps, bloated chat apps like slack, teams, element, discord, web framework mess,etc.. is this the chaos we want to leave the next generation? It might take a long time, but isn't it good to "build trees under whose shade you'll never sit"?
• vishnuharidas 7mo ago
  Nothing can't be first-class as long as it is not *directly* replacing the existing first-class citizens. If Wasm modules can be loaded like this: <wasm src="/module.wasm" start="main" data="..." /> ...and if Wasm could access the DOM like this: import dom, json, re, html, urllib.parse from datetime import datetime params = urllib.parse.urlencode({"category": "news", "limit": 10}) data = json.loads(await (await fetch(f"https://api.example.com/data?{params}")).string()) container = js.document.getElementById("app") container.innerHTML = "".join(f"..." for i in data["items"]) ...then developers would have jumped in right away.
  • troad 7mo ago
    The oldest story in tech standards; a play in three acts: > "We've developed Foo 2.0. It does not have feature parity with Foo 1.0, but it's more architecturally elegant in ways that are meaningless to the public. It took ten thousand man hours and was done instead of much needed upgrades to Foo 1.0." *one year later* > "Why is no one adopting Foo 2.0? Yes, it doesn't have feature parity with Foo 1.0, but it's frankly irresponsible of the public not to understand that 2.0 is a higher number than 1.0." *ten years later* > "Remember Foo? What a mess. Thank god Bar came along." *eleven years later* > "Announcing Bar 2.0... "
• okcdz 7mo ago
  I think WASM's real problem is language fragmentation. For 3D apps, C++ makes sense. But Go and other GC languages don't perform well on WASM - they implemented their own GC anyway. And honestly, I don't see the advantage of writing web apps in Rust over JS. The ecosystem, tooling, and debugging are all better with JS.
• WhereIsTheTruth 7mo ago
  I already hate it There is a massive, pathetic drop in quality from the system designs of the past compared to the garbage we are seeing nowadays You can tell they are fully embracing slop and stupid design Tehy are trading efficiency and elegance for bloat, and it is absolute trash They have stopped engineering, they abstraction junkies OGs don't want to be associated with any of that trash, and it shows
• TheLNL 7mo ago
  Say goodbye to writing multiple kinds of plugins and userscripts for random websites I guess. I don't want the transition to wasm because it looks like it will make most things unchangeable binary blobs
  • zeratax 7mo ago
    I don't follow? when you write userscripts you modify the dom not the already running scripts usually, no?
    • TheLNL 7mo ago
      Wouldn't there be a point where the mainstream approach is to just have compiled blobs write directly to the canvas, say a point where someone compiles a qt application and hosts it on their website. What can you even modify there, when all the structure is flattened into a single layer
      • bvisness 7mo ago
        You can already make apps that write directly to a canvas today, and almost nobody does because they want what the DOM provides for them. Wasm changes nothing about the APIs available to web apps.
• foota 7mo ago
  It would be fascinating if someday you could implement parts of the browser using WASM modules.
• yunseo47 7mo ago
  I agree with the direction, but it seems to miss the golden hour. This concept should have been on the roadmap at least several years ago. After all, in most use cases, execution speed is not the main issue with JavaScript. I believe that the need for JavaScript glue code has significantly hindered the appeal and interest in WASM, as well as the resulting ecosystem growth.
• u1hcw9nx 7mo ago
  This was supposed to happen already in the 2000s. JVM in everywhere, especially in the browser. There was Java rings you could wear, Java Card VM (JCVM), Squawk VM, Java ME. "Java the language is almost irrelevant. It's the design of the Java Virtual Machine. And I've seen compilers for ML, compilers for Scheme, compilers for Ada, and they all work. Not many people use them, but it doesn't matter: they all work." --James Gosling Then Microsoft happened. MS realized that "Write Once, Run Anywhere" kills their OS monopoly, so they polluted Java with brilliant Embrace, Extend, Extinguish strategy (Sun vs. Microsoft revealed the emails where the stated goal was "Kill cross-platform Java" by growing the "polluted" Java market.): Embrace: Microsoft licensed Java from Sun Microsystems and built the MSJVM. It was the fastest JVM for some time. Extend: They created a programmer tool for Java with proprietary Windows-specific "extensions" and also removed standard features like RMI and JNI. Extinguish: Developers using MS tools (90% of devlopers at the time) produced "Write Once, Run Only on Windows" software and killed it and pivoted to C# and .NET
  • gumby271 7mo ago
    Which is very much Google's approach to Android. AOSP could be targeted directly by devs, but Google pushes everyone to use Google services in their apps (and assume it's available on any android device) which means Android with Google services is the only viable version of Android out there.
    • u1hcw9nx 7mo ago
      Google and Apple both. Most "apps" in phones could be just something you install trough browser and cache in a sandbox if we developed good standards.
  • wffurr 7mo ago
    JVM bytecode didn't have support for C and required GC. Even in the early days it was a lot heavier than Wasm.
    • u1hcw9nx 7mo ago
      JCVM did not require GC. It was designed to run on extremely resource-constrained devices-think 16-bit or 32-bit microcontrollers with only a few kilobytes of RAM. Java Card 2.2 and 3.x specifications added optional GC.
• pmkary 7mo ago
  Not only are they a decade late while everyone expected WASM to liberate us from JS, and it ended up being a useless toy in JS whose improvements would have been crushed by having to send all progress to JS to apply it, but then giving it access to DOM is also something you'll realize wasn't enough a decade later. Flutter doesn't need DOM; it has all of its own engine. The browser should give the whole viewpoint to the WASM so that apps can directly implement their own GUIs. And then there will be an app revolution. You can directly port your GUI to the web and have it work. No more your GUI as a WASM worker that has to have its frames painted by JS on a canvas; direct painting. You could have wxWidgets, GTK, Flutter, ... all working insanely fast, insanely beautiful. And then people can do amazing things. Imagine a web alternative that is powered by maestro Knuth's TeX; imagine operating systems as web pages, imagine alternative layout systems that do not have to rely on Web events and frame timing. That is all if the browser allows for WASM to bypass the web part and do it itself.
  • fzzzy 7mo ago
    And it would be 100% inaccessible.
    • gzread 7mo ago
      You can't pin requirements on other people who don't have them. If someone doesn't have a requirement to make an accessible product, it's unlikely to be accessible.
    • pmkary 7mo ago
      Basically this has been the only way to stop anything from happening. But major systems all have accessibility like web and if someone wants to support accessibility they will do it there. Those who don't, won't even do it on web. If something like I say happens, not only accessibility will be lost, but so much more will be lost too. But then if you need it you'll either implement it or use web. Figma, SketchUp, and Google Docs have their software rendered on a canvas. For them this would have made things much faster. It is giving people options. Personally I hate web. It is horrible to write software by manipulating DOM and having to work with CSS. Every time I touch html/js/css I think why can't it be a nice system? Why I have no control over rendering? At least I would have loved to have an alternative the whole web and dom, and would have killed for writing web pages like a flutter app.
• speefers 7mo ago
  [dead]
• utopiah 7mo ago
  I feel like the bottleneck for WASM integration isn't WASM itself but rather how to interface with it. Quite often it comes with a mandatory service worker which has to be communicated to in a specific fashion, then some specific headers need to be available server side, etc. I'm not saying it's not required but ... I imagine most Web developer are used to requiring a library, calling its function, getting the result. Until it reaches that stage then JavaScript fallbacks will be preferred until there is absolutely no alternative but the WASM binary. PS: this might sound like such a low bar... but the alternative is giving up entirely on either, starting a container with a REST API then calling it with a client. That's very easy and convenient when you've done it once and you decouple. So maybe I'm finicky but when very popular alternatives exist I believe the tipping point won't happen unless it becomes radically easier than what exists.
• sriramgonella 7mo ago
  [flagged]
• tom_m 7mo ago
  ActionScript, Emscripten, Dart, WebAssembly... All things that perform better and are often better to use than JavaScript (and TypeScript) and the dumb masses chose the crap we have now. Let's face it. People benefit from complexity and poorly performing apps. Not just for the web, look at video game engines too. When hardware gets faster and cheaper, people tend to say "meh" to quality and performance concerns. That part gets easier, but that's the slippery slope that introduces poor quality and complexity - especially when pressured top down by companies to go faster. Basically the need for, forget about reward in, quality is completely removed. So congratulations Internet. We have most web apps powered by a language spec dreamt up in a weekend. With patches on top of patches and abstraction on top of abstraction since. It's been great job security of course... gatekeeping and all...but I don't know. I kinda hope AI does come and just replaces it all or something. Man I wanted to use WebAssembly more. For Dart I made a Photoshop PSD to JPG converter that was super fast too. Much faster than any JavaScript image convert and resize was. Bummer.