4 ms·

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects Just a note, but there is burgeoning support for this in "modern

• valorzard 1y ago
  You should write an article about this stuff and post it here since this is the first time I’m hearing about all of this
• landonxjames 1y ago
  I have used Jco quite a bit (and contributed a few times) to build out simple utilities binding Rust code to JS [1][2]. I think it is great and the Component Model is the most exciting step towards real useful polyglot libraries I have seen in years. I wish it were better publicized, but I understand keeping things lowkey until it is more fleshed out (the async and stream support coming in Preview 3 are the real missing pieces for my usecases). [1] https://github.com/awslabs/aws-wasm-checksums https://github.com/awslabs/aws-wasm-checksums [2] https://github.com/landonxjames/aws-sdk-wasi-example https://github.com/landonxjames/aws-sdk-wasi-example
  • hardwaresofton 1y ago
    Thanks for using and contributing to Jco! > (the async and stream support coming in Preview 3 are the real missing pieces for my usecases). Currently this is a huge focus of most of the people working on stuff, and Jco is one of the implementations that needs to be done before P3 can ship, so we're hard at work on it. > exciting step towards real useful polyglot libraries I have seen in years I certainly agree (I'm biased) -- I think it's going to be a kind of tech that is new for a little bit and then absolutely everywhere and mostly boring. I think the docker arc is almost guaranteed to happen again, essentially. The architectural underpinnings, implementation, and possibilities unlocked by this wave of Wasm is amazing -- truly awesome stuff many years in the making thanks to many dedicated contributors.
• dfabulich 1y ago
  I think it's a huge exaggeration to say "the support for DOM stuff is ready now." When writing most non-web software, you can usually write it quickly in a high-level language (with a rich standard library and garbage collection), but you can get better performance (with more developer effort) by writing your code in a lower-level language like C or Rust. What developers are looking for is a way to take UI-focused DOM-heavy web apps, RIIR, and get a performance improvement in browsers. That is not ready now. It's not even close. It might literally never happen. What is ready now is a demo project where you can write WASM code against a DOM-like API running in Node.js. What you have is an interesting demo, but that's not what we mean when we ask when WASM will get "DOM support."
  • hardwaresofton 1y ago
    > What developers are looking for is a way to take UI-focused DOM-heavy web apps, RIIR, and get a performance improvement in browsers. Could you expand a bit on waht you expect would make this possible? What would you list as the most important blockers right now stopping people from getting there in your mind?
    • dfabulich 1y ago
      Honestly, I can't believe you're asking me this! You're so far in the weeds of the WASM component model that you have no idea what the problem is. It's really silly to ask what the "most important blockers" are, as if it's a list of bugs that can be fixed. But, sure, in good faith, here's the problem. Today, if you take a UI-focused DOM-heavy web app that makes lots and lots of DOM API calls (i.e. most JS web apps ever written) and try to rewrite it in Rust, you'll have to cross the boundary between JS and WASM over and over again, every time you use a DOM API. Every time you add/remove/update an element, or its styles, or handle a click event, you'll cross the boundary. The boundary is slow because every time you touch a JS string (all CSS styles are strings!), you'll have to serialize it (in JS) into a byte array and send it into WASM land, do your WASM work, transfer back a byte array, and deserialize it into a JS string. (In the bad old days you had to copy the byte array in and out to do any I/O, but at least we have reference types now.) And it's not just strings. All JS objects that you need to do actual work with have to be serialized/deserialized in this way, because WASM only knows about bytes, arrays, and opaque pointers. DOM elements/attributes, DOM style properties, DOM events (click events, keyboard events, etc.), all of them get slow when you transfer them in and out of WASM land, even with reference types, because of serialization/deserialization. WASM interface types will make it easier to call JS from WASM, but as long as you're still calling JS in the end, rewriting in Rust will never make a DOM-heavy web app faster than writing it in JS. That's why this sucks! Rewriting a Node.js app in Rust (or Go or Zig, etc.) normally yields huge performance gains (at huge developer effort), but rewriting a JS DOM-heavy web app in Rust just slaps Rust on top of JS; it usually makes it slower. The only fix, as Daniel's article explains, would be to standardize a low-level DOM API, one that didn't assume that you can use JS strings, objects+properties, exceptions, promises, etc. This would be an unimaginably large standardization project. You couldn't use WebIDL at all; you'd need to start by defining a new "low-level WebIDL." Then, you'd start standardizing the entire DOM API, all over again (or at least the most important parts) in low-level WebIDL, and then browser vendors could start implementing the low-level DOM API. Then WASM could start calling that API directly. And maybe then you could rewrite web apps in Rust and have them get faster. Until then, WASM is only faster for CPU-intensive tasks with I/O at the beginning/end, and otherwise it's only good for legacy code, where you don't have time to make it faster by rewriting it in JS. (It should sound insane to anyone that taking C++ and rewriting it in JS would make it faster, but that's how it is on the web, because of this WASM boundary issue.) So, what's the most important blocker? (gesture toward the universe) All of it??