4 ms·

We didn’t need wasm to compile to the web for decades prior. Having a target closer to machine code is good, but not revolutionary. Same for Photoshop on the we

We didn’t need wasm to compile to the web for decades prior. Having a target closer to machine code is good, but not revolutionary. Same for Photoshop on the web tbh. Who is even using this?

afavour 3y ago
You’re asking who is using Photoshop on the web? A lot of people. Like there’s a ton of people using Office 365 in a browser rather than the native app. HN loves to shit on webapps and honestly with very good reason but the reality is that for a lot of people a cloud-based app they can use on absolutely any computer (or, often, phone/tablet) they can get their hands on is a huge boon.
- 3cats-in-a-coat 3y ago
  Absolutely any computer/phone/tablet has the concept of applications. Web apps remove initial friction of installation, and for big apps not even that much because you still need to download it and run it. But they also pay up this gain, with huge interest, for every single second you use the app. This is not benefitting the users. The bottom line is dire. However removing initial friction is all about getting your foot in the door. It's like selling a printer under cost and then you get them with the ink. Get them the first drug dose free, and then you get them when they're dependent. Offer a cheap design, and then you destroy them with the manufacturing. A story as old as the world, of which this "web megaapp" model is a tiny microcosm of. The web is an excellent platform for small to medium apps. Photoshop is gigantic. And Figma and the other rest of its ilk are absolutely insufferable and I'm saying this as a webdev. I would be significantly happier if these products did NOT exist. Heck if we took out WASM and these kind of products went away I'd consider it a net positive.
  - pjmlp 3y ago
    Android instant apps do exactly the same nowadays.
mfer 3y ago
WASM is very useful for things outside the web. Consider that a WASM build can be run server side on multiple OS and arch. The same build. The API can be controlled and locked down (think security). The web is not the most interesting place for WASM.
- 3cats-in-a-coat 3y ago
  You can also run the same build when there's no OS fragmentation. Say all Windows machines run the same build. All iPhones run the same build (well not quite, but let's say they automated and hid the builds very efficiently on the App Store, zero effort). All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture. However none of this matters. Because we have Java and countless other cross-platform runtimes. WASM is at best just another variation on the same theme thrown in the same pool. I definitely see how one could justify WASM hype by saying all the things will be WASM because it's so sandboxed and multiplatform. But that's the engine of all hype cycles. Truth is it likely won't happen, because WASM is nothing new and nothing unique. That niche is filled with solutions already. We could theorize everyone will have a WASM compiler backend because it runs in browsers, therefore it'll become more useful on servers as you have compiler backend for everything to WASM. However YOU yourself said the web is not the most interesting place for WASM. So what will supposedly drive the WASM ecosystem, that makes it interesting (the web) isn't interesting, but it has to be interesting so the server use of WASM becomes more interesting. Quite the chicken egg problem there. Might work, might not. I lived through a period on the web when every language had a JS compiler backend. You could compile Java to JS, Delphi to JS, C# to JS and so on. Maybe some of those solutions still exist in some half-dead form, but they're largely abandoned, because people realized the best language to write JS in... is JS. This is also why TypeScript has such success, because it's JavaScript itself (but with types). For WASM we can argue there's no such pressure to "write JS in JS" but there's just very little value for it, outside the nerd realm of "OMG assembly on the web". I know why Google wants it. It wants it because it indexes the web, and puts ads on the web, and so therefore it wants everything to be the web, because then it means Google can index and put ads on everything. That's good for them, but not for anyone else. Downloading and running hundreds of MB of code for an app like Photoshop, or whatever, over the web is an absolutely miserable experience. Not to mention the HCI input capabilities and OS services available to the app, which are understandably limited in a browser.
matthewowen 3y ago
Figma is built using WASM, sees significant benefit from it, and is pretty popular. But absolutely there are a lot of of less demanding web applications out there that don’t need this. And in the case of Figma, it’s the core of the application that uses WASM, with the more webby UI bits outside of it for all the devex reasons you’d expect. In truth it’s a medium deal in the sense that it enables use cases that simply aren’t feasible without it, but is arguably irrelevant for most “conventional” web dev problems. In that vein I’d argue it is more relevant for use cases that currently aren’t on the web at all versus as an improvement for those that are.
- 3cats-in-a-coat 3y ago
  I can’t stand Figma, it’s limited, slow and in general, demonstrating nothing at all for its wasm use so that’s kind in support of my point. Something like Figma would get a lot more performance out of using WebGL. Which is only accessible through JS, and the emscripten bindings for it go through JS calls. So WASM is kind of a dead weight in this scenario.
  - paulgb 3y ago
    The company was last valued at $20B so they are doing something right. They are using WebGL. Using WebGL from WebAssembly has some nice advantages; with Wasm you can use languages that are more accommodating to the sort of densely-packed data that you need to send to GPU buffers. Here’s an interview I did with a raster graphics editor that touches on why they use Wasm for GPU. https://digest.browsertech.com/archive/browsertech-digest-how-modyfi-is-building-with/ https://digest.browsertech.com/archive/browsertech-digest-ho...
    - 3cats-in-a-coat 3y ago
      Accommodating how? Everything goes through JS, what they share is basically an ArrayBuffer (if we're talking command buffers) which you can build directly in JS with the same JIT backend that powers WASM. I went through your article but it doesn't describe how is WASM more "accomodating" to this. One way or another, the command buffers are an encoding process. They're not WASM code nor JS code, they're GPU code. You need to build them from one platform for another platform. There's no any direct correspondence between WASM and WebGPU, let alone WebGL.

We didn’t need wasm to compile to the web for decades prior. Having a target closer to machine code is good, but not revolutionary. Same for Photoshop on the web tbh. Who is even using this?

afavour 3y ago

You’re asking who is using Photoshop on the web? A lot of people. Like there’s a ton of people using Office 365 in a browser rather than the native app. HN loves to shit on webapps and honestly with very good reason but the reality is that for a lot of people a cloud-based app they can use on absolutely any computer (or, often, phone/tablet) they can get their hands on is a huge boon.

3cats-in-a-coat 3y ago
Absolutely any computer/phone/tablet has the concept of applications. Web apps remove initial friction of installation, and for big apps not even that much because you still need to download it and run it. But they also pay up this gain, with huge interest, for every single second you use the app. This is not benefitting the users. The bottom line is dire. However removing initial friction is all about getting your foot in the door. It's like selling a printer under cost and then you get them with the ink. Get them the first drug dose free, and then you get them when they're dependent. Offer a cheap design, and then you destroy them with the manufacturing. A story as old as the world, of which this "web megaapp" model is a tiny microcosm of. The web is an excellent platform for small to medium apps. Photoshop is gigantic. And Figma and the other rest of its ilk are absolutely insufferable and I'm saying this as a webdev. I would be significantly happier if these products did NOT exist. Heck if we took out WASM and these kind of products went away I'd consider it a net positive.
- pjmlp 3y ago
  Android instant apps do exactly the same nowadays.

mfer 3y ago

WASM is very useful for things outside the web. Consider that a WASM build can be run server side on multiple OS and arch. The same build. The API can be controlled and locked down (think security). The web is not the most interesting place for WASM.

3cats-in-a-coat 3y ago
You can also run the same build when there's no OS fragmentation. Say all Windows machines run the same build. All iPhones run the same build (well not quite, but let's say they automated and hid the builds very efficiently on the App Store, zero effort). All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture. However none of this matters. Because we have Java and countless other cross-platform runtimes. WASM is at best just another variation on the same theme thrown in the same pool. I definitely see how one could justify WASM hype by saying all the things will be WASM because it's so sandboxed and multiplatform. But that's the engine of all hype cycles. Truth is it likely won't happen, because WASM is nothing new and nothing unique. That niche is filled with solutions already. We could theorize everyone will have a WASM compiler backend because it runs in browsers, therefore it'll become more useful on servers as you have compiler backend for everything to WASM. However YOU yourself said the web is not the most interesting place for WASM. So what will supposedly drive the WASM ecosystem, that makes it interesting (the web) isn't interesting, but it has to be interesting so the server use of WASM becomes more interesting. Quite the chicken egg problem there. Might work, might not. I lived through a period on the web when every language had a JS compiler backend. You could compile Java to JS, Delphi to JS, C# to JS and so on. Maybe some of those solutions still exist in some half-dead form, but they're largely abandoned, because people realized the best language to write JS in... is JS. This is also why TypeScript has such success, because it's JavaScript itself (but with types). For WASM we can argue there's no such pressure to "write JS in JS" but there's just very little value for it, outside the nerd realm of "OMG assembly on the web". I know why Google wants it. It wants it because it indexes the web, and puts ads on the web, and so therefore it wants everything to be the web, because then it means Google can index and put ads on everything. That's good for them, but not for anyone else. Downloading and running hundreds of MB of code for an app like Photoshop, or whatever, over the web is an absolutely miserable experience. Not to mention the HCI input capabilities and OS services available to the app, which are understandably limited in a browser.

matthewowen 3y ago

Figma is built using WASM, sees significant benefit from it, and is pretty popular. But absolutely there are a lot of of less demanding web applications out there that don’t need this. And in the case of Figma, it’s the core of the application that uses WASM, with the more webby UI bits outside of it for all the devex reasons you’d expect. In truth it’s a medium deal in the sense that it enables use cases that simply aren’t feasible without it, but is arguably irrelevant for most “conventional” web dev problems. In that vein I’d argue it is more relevant for use cases that currently aren’t on the web at all versus as an improvement for those that are.

3cats-in-a-coat 3y ago
I can’t stand Figma, it’s limited, slow and in general, demonstrating nothing at all for its wasm use so that’s kind in support of my point. Something like Figma would get a lot more performance out of using WebGL. Which is only accessible through JS, and the emscripten bindings for it go through JS calls. So WASM is kind of a dead weight in this scenario.
- paulgb 3y ago
  The company was last valued at $20B so they are doing something right. They are using WebGL. Using WebGL from WebAssembly has some nice advantages; with Wasm you can use languages that are more accommodating to the sort of densely-packed data that you need to send to GPU buffers. Here’s an interview I did with a raster graphics editor that touches on why they use Wasm for GPU. https://digest.browsertech.com/archive/browsertech-digest-how-modyfi-is-building-with/ https://digest.browsertech.com/archive/browsertech-digest-ho...
  - 3cats-in-a-coat 3y ago
    Accommodating how? Everything goes through JS, what they share is basically an ArrayBuffer (if we're talking command buffers) which you can build directly in JS with the same JIT backend that powers WASM. I went through your article but it doesn't describe how is WASM more "accomodating" to this. One way or another, the command buffers are an encoding process. They're not WASM code nor JS code, they're GPU code. You need to build them from one platform for another platform. There's no any direct correspondence between WASM and WebGPU, let alone WebGL.