5 ms·

Pretty cool. I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely benef

Pretty cool. I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development. Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are required. Net benefit for all web devs - faster libraries, impressive dev tools and more portable node binaries.

danielvaughn 3y ago
I've been watching WASM from afar, and it's my understanding that it's not a JS killer because it doesn't have direct access to the DOM or to most DOM APIs. I'm curious if there's another reason I'm missing?
- ReleaseCandidat 3y ago
  It doesn't have access to _anything_ (in the browser, in other runtimes there is WASI with POSIX functions). Everything has to be imported from or exported to JS. And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
  - yebyen 3y ago
    > isn't feasible This is kind of subjective, and in the context of "is this a JS killer" which is what you're answering, I'd agree, it makes sending the Wasm to the browser a bit of a non-starter that it requires a large bundle most of which is simply boilerplate for whatever runtime, without some type of local storage and persistent cache it's difficult to imagine using Ruby in a Wasm for example. If you're deploying to a container, where you're able to use a cache warmer to ensure the wasm is ready before it's called, then a 1mb binary might not be such a big issue. (I mean, it is still a big issue because the point was fast cold starts, and big assemblies mean no fast cold starts, but again, subjective value judgments... 1mb isn't too big in many cases and I'd wager most of the cases that I'd really care about. But in a browser...) But if you're not trying to run the Wasm in a browser then it's still potentially quite useful. You might not be running all of your Wasm in a browser and it might still be a JS killer, and all of those might not be in conflict.
    - ReleaseCandidat 3y ago
      Well, the main reason why I'm taking a deeper look at WASM is because I'm creating a language and compiler that is optimized to compile to WASM. While I don't think that my compiler will be the JS killer, I do think that WASM languages using a (the WASM) GC have a future.
  - titzer 3y ago
    Virgil compiles to Wasm and brings its own GC as well, and the runtime is on the order of about 4KB. The GC is a simple semi-space copying collector and the compiler prunes away dead code from libraries, so binaries are pretty small. So overall I don't think this is a Wasm issue as it is mostly a language runtime size issue.
  - plopz 3y ago
    In the browser, can it integrate with SharedArrayBuffer, worker's postMessage or transferrable offscreen canvas?
    - connicpu 3y ago
      WASM essentially can call javascript functions that were imported, and I believe javascript is able to read WASM's memory (a big help for transferring strings). If you're using something like Rust, all the glue code to call any JS APIs can be automatically generated for you with wasm-bindgen, so it really isn't a huge problem usability wise. It's just not great for performance.
    - ReleaseCandidat 3y ago
      Depends what you mean by "integrate". It always has to import or export JS functions or memory. WASM (without WASI) has no direct connection to "the outside World", everything has to be routed via JS FFI. So you can import or export a SharedArrayBuffer to communicate with JS. https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory#creating_a_shared_memory https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScr... But you need the WASM thread extension (for atomic access to the shared memory) to be able to use shared memory.
  - patmorgan23 3y ago
    I mean Microsofts Blazor framework can use WASM to run C#(and its runtime) in the browser.
  - dragonwriter 3y ago
    > And currently using anything but C, C++ or Rust isn't feasible Someone should tell Anaconda that they can't do this, then: https://pyscript.net/ https://pyscript.net/
    - tyingq 3y ago
      That uses Pyodide. From Pyodide's own pages: "At present a first load of Pyodide requires a 6.4 MB download, and the environment initialization takes 4 to 5 seconds." So, yes, it works. But there's plenty of situations where a big download followed by a 5 second stall is a non-starter.
  - progmetaldev 3y ago
    I do agree things like the GC are very large if we're comparing against standard JavaScript, so I don't believe the technology is ready for standard customer facing websites. For things like internal applications/extranet type applications, I think that the runtime download cost is minimal compared to the functionality that you are given with a proper framework (I can only speak of Microsoft Blazor, but that's just language ignorance, and I know there are other that fit the model as well). As a web developer that also writes utilities to run on the desktop, for things such as ETL or fixing bad data, being able to not switch to another language or even really framework is a huge boon for my time. I know JavaScript, but being able to rarely have to deal with it keeps my head in what I'm solving, rather than having to context switch between interface and server.
- lenkite 3y ago
  Yep. Give access to the DOM - perhaps via a batch update/fragment mechanism and watch as it becomes a JS killer. But WASM is currently a starved prisoner locked up in a room only allowed to view the goodies outside the cell door.
  - tcfhgj 3y ago
    What would that change? DOM interaction can and is abstracted away by frameworks anyways and not performance critical
- math_dandy 3y ago
  Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser. Let WASM do the number crunching, let JS do the UI.
  - Philip-J-Fry 3y ago
    It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point. For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers are basically just becoming their own platform like Windows Desktop, Mac, Linux, Android, iOS, etc. You could say it's been that way for a long time, but more and more apps are becoming web based only because the browser is now powerful enough to run what used to be a desktop application. Browsers are literally just a VM with an address bar. We go to a URL and run a program, except right now there's basically the limitation that the program has to be written at least partly in JavaScript. Being able to deploy an entire website as WASM is just the next logical step from what I see.
    - math_dandy 3y ago
      The two language problem is, indeed, awkward. DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. In the meantime, WASM has real, just not for front end dev. The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.
      - catlover76 3y ago
        > I would be a happy nerd if I could do all of my web dev in OCaml. You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?

danielvaughn 3y ago

I've been watching WASM from afar, and it's my understanding that it's not a JS killer because it doesn't have direct access to the DOM or to most DOM APIs. I'm curious if there's another reason I'm missing?

ReleaseCandidat 3y ago
It doesn't have access to _anything_ (in the browser, in other runtimes there is WASI with POSIX functions). Everything has to be imported from or exported to JS. And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
- yebyen 3y ago
  > isn't feasible This is kind of subjective, and in the context of "is this a JS killer" which is what you're answering, I'd agree, it makes sending the Wasm to the browser a bit of a non-starter that it requires a large bundle most of which is simply boilerplate for whatever runtime, without some type of local storage and persistent cache it's difficult to imagine using Ruby in a Wasm for example. If you're deploying to a container, where you're able to use a cache warmer to ensure the wasm is ready before it's called, then a 1mb binary might not be such a big issue. (I mean, it is still a big issue because the point was fast cold starts, and big assemblies mean no fast cold starts, but again, subjective value judgments... 1mb isn't too big in many cases and I'd wager most of the cases that I'd really care about. But in a browser...) But if you're not trying to run the Wasm in a browser then it's still potentially quite useful. You might not be running all of your Wasm in a browser and it might still be a JS killer, and all of those might not be in conflict.
  - ReleaseCandidat 3y ago
    Well, the main reason why I'm taking a deeper look at WASM is because I'm creating a language and compiler that is optimized to compile to WASM. While I don't think that my compiler will be the JS killer, I do think that WASM languages using a (the WASM) GC have a future.
- titzer 3y ago
  Virgil compiles to Wasm and brings its own GC as well, and the runtime is on the order of about 4KB. The GC is a simple semi-space copying collector and the compiler prunes away dead code from libraries, so binaries are pretty small. So overall I don't think this is a Wasm issue as it is mostly a language runtime size issue.
- plopz 3y ago
  In the browser, can it integrate with SharedArrayBuffer, worker's postMessage or transferrable offscreen canvas?
  - connicpu 3y ago
    WASM essentially can call javascript functions that were imported, and I believe javascript is able to read WASM's memory (a big help for transferring strings). If you're using something like Rust, all the glue code to call any JS APIs can be automatically generated for you with wasm-bindgen, so it really isn't a huge problem usability wise. It's just not great for performance.
  - ReleaseCandidat 3y ago
    Depends what you mean by "integrate". It always has to import or export JS functions or memory. WASM (without WASI) has no direct connection to "the outside World", everything has to be routed via JS FFI. So you can import or export a SharedArrayBuffer to communicate with JS. https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory#creating_a_shared_memory https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScr... But you need the WASM thread extension (for atomic access to the shared memory) to be able to use shared memory.
- patmorgan23 3y ago
  I mean Microsofts Blazor framework can use WASM to run C#(and its runtime) in the browser.
- dragonwriter 3y ago
  > And currently using anything but C, C++ or Rust isn't feasible Someone should tell Anaconda that they can't do this, then: https://pyscript.net/ https://pyscript.net/
  - tyingq 3y ago
    That uses Pyodide. From Pyodide's own pages: "At present a first load of Pyodide requires a 6.4 MB download, and the environment initialization takes 4 to 5 seconds." So, yes, it works. But there's plenty of situations where a big download followed by a 5 second stall is a non-starter.
- progmetaldev 3y ago
  I do agree things like the GC are very large if we're comparing against standard JavaScript, so I don't believe the technology is ready for standard customer facing websites. For things like internal applications/extranet type applications, I think that the runtime download cost is minimal compared to the functionality that you are given with a proper framework (I can only speak of Microsoft Blazor, but that's just language ignorance, and I know there are other that fit the model as well). As a web developer that also writes utilities to run on the desktop, for things such as ETL or fixing bad data, being able to not switch to another language or even really framework is a huge boon for my time. I know JavaScript, but being able to rarely have to deal with it keeps my head in what I'm solving, rather than having to context switch between interface and server.
lenkite 3y ago
Yep. Give access to the DOM - perhaps via a batch update/fragment mechanism and watch as it becomes a JS killer. But WASM is currently a starved prisoner locked up in a room only allowed to view the goodies outside the cell door.
- tcfhgj 3y ago
  What would that change? DOM interaction can and is abstracted away by frameworks anyways and not performance critical
math_dandy 3y ago
Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser. Let WASM do the number crunching, let JS do the UI.
- Philip-J-Fry 3y ago
  It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point. For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers are basically just becoming their own platform like Windows Desktop, Mac, Linux, Android, iOS, etc. You could say it's been that way for a long time, but more and more apps are becoming web based only because the browser is now powerful enough to run what used to be a desktop application. Browsers are literally just a VM with an address bar. We go to a URL and run a program, except right now there's basically the limitation that the program has to be written at least partly in JavaScript. Being able to deploy an entire website as WASM is just the next logical step from what I see.
  - math_dandy 3y ago
    The two language problem is, indeed, awkward. DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. In the meantime, WASM has real, just not for front end dev. The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.
    - catlover76 3y ago
      > I would be a happy nerd if I could do all of my web dev in OCaml. You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?