4 ms·

Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compil

by rdtsc 3y ago

Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compiled languages, we can play cool games built in C and such in the browser. It also has this property that it makes for very cool demos. It may be useful or not in larger production environments, but it's hard to deny that it looks cool when being showed off. The danger is when someone in charge becomes enamored by it and now the whole 20 person team is spending the next two years rewriting a production system in it.

phendrenad2 3y ago
Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737
gwervc 3y ago
> Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).
- joquarky 3y ago
  Also, Java applets and ActiveX objects were notoriously lacking in accessibility. I see the same happening with WASM-based web apps if they don't find an elegant way to directly utilize the DOM.
  - genman 3y ago
    That is my main concern and I am following this WASM story with growing caution.
  - PaulDavisThe1st 3y ago
    Cardinal [0] is a wasm-based web app. What on earth would the DOM have to do with a modular synthesis environment? You seem to be imagining that wasm-based web apps implies a fairly strong connection to existing HTML/CSS/JS "pages". This is not the case and is an unnecessary cognitive barrier to thinking about what wasm (in-browser) could make possible. [0] https://cardinal.kx.studio/live https://cardinal.kx.studio/live
    - filleduchaos 3y ago
      And it's lacking in accessibility, just as the person you're responding to said. > What on earth would the DOM have to do with a modular synthesis environment? The fact that unlike people's cool and dreamy bespoke UIs drawn entirely on canvas, the DOM does actually have a competently implemented accessibility services layer that apps using it get for free out of the box. Not to mention that you've never needed WASM to draw UIs entirely on canvas either. It's a silly idea with JS and a silly idea with WASM.
      - PaulDavisThe1st 3y ago
        This application is written in C++. It has no accessibility features because nobody has ever figured how to do that with a virtual modular synthesis environment that is absolutely intended to be (a) extremely skeuomorphic (b) extremely visual. The same issue exists in the native world too, and isn't going to be solved by somehow connecting a DOM with the canvas.

by rdtsc 3y ago

phendrenad2 3y ago

Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737

gwervc 3y ago

> Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).

joquarky 3y ago
Also, Java applets and ActiveX objects were notoriously lacking in accessibility. I see the same happening with WASM-based web apps if they don't find an elegant way to directly utilize the DOM.
- genman 3y ago
  That is my main concern and I am following this WASM story with growing caution.
- PaulDavisThe1st 3y ago
  Cardinal [0] is a wasm-based web app. What on earth would the DOM have to do with a modular synthesis environment? You seem to be imagining that wasm-based web apps implies a fairly strong connection to existing HTML/CSS/JS "pages". This is not the case and is an unnecessary cognitive barrier to thinking about what wasm (in-browser) could make possible. [0] https://cardinal.kx.studio/live https://cardinal.kx.studio/live
  - filleduchaos 3y ago
    And it's lacking in accessibility, just as the person you're responding to said. > What on earth would the DOM have to do with a modular synthesis environment? The fact that unlike people's cool and dreamy bespoke UIs drawn entirely on canvas, the DOM does actually have a competently implemented accessibility services layer that apps using it get for free out of the box. Not to mention that you've never needed WASM to draw UIs entirely on canvas either. It's a silly idea with JS and a silly idea with WASM.
    - PaulDavisThe1st 3y ago
      This application is written in C++. It has no accessibility features because nobody has ever figured how to do that with a virtual modular synthesis environment that is absolutely intended to be (a) extremely skeuomorphic (b) extremely visual. The same issue exists in the native world too, and isn't going to be solved by somehow connecting a DOM with the canvas.