4 ms·

> 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 t

by 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 gwervc 3y ago

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.