4 ms·

I'm a web dev and I don't know much about WASM. I've been wondering - will it be possible to render something to the screen without first going through the DOM?

I'm a web dev and I don't know much about WASM. I've been wondering - will it be possible to render something to the screen without first going through the DOM? Or is the DOM literally the only way to display content? It's enticing to imagine being able to open a wasm file and seeing an application on the page. Kinda like how you can just open an image or a video in the browser, without rendering it via an html document.

klodolph 7y ago
There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code. Of course, why not just use a small HTML+JS shim for your WASM?
- AnIdiotOnTheNet 7y ago
  Because there is value in ditching legacy cruft.
  - klodolph 7y ago
    That’s a short-term view. There’s going to be legacy cruft either way. Either we have the existing HTML + JS with WASM alongside it, or we introduce a ton of new APIs to let WASM function by itself. Using the existing HTML + JS avoids creating as much future legacy cruft.
  - pdpi 7y ago
    You still capture the vast majority of that value by having a minimal “legacy cruft” loader that sets up, and passes control to, the modern toolchain
  - paulhodge 7y ago
    HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.
    - weberc2 7y ago
      This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.
      - pron 7y ago
        I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
        throwaway894345 7y ago
        I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.
        pron 7y ago
        It has not been my perception that that's an aspiration or a goal of WASM, but there's much I haven't read. Can you point me to where this is stated as one of WASM's goals?
        throwaway894345 7y ago
        https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/ > 3. Design to execute within and integrate well with the existing Web platform: > * execute in the same semantic universe as JavaScript > * access browser functionality through the same Web APIs that are accessible to JavaScript Lawyering aside, I would say that this is pretty much the same thing as "enabling the development in web apps in other languages".
  - BlueTemplar 7y ago
    If you don't want cruft, don't make a browser-based app?
- drfuchs 7y ago
  Because it slows things down by 3 or 4 orders of magnitude?
calaphos 7y ago
You can take a Canvas element and draw anything you like on it - even hardware accelerated 3d using webGL. I think there are some projects trying to (re) implement a 2d user interface, rendered onto canvas. However the issue id that you will need to reimplement a lot of things the browser already does for you: rendering text, scaling, zoom, input methods, highlighting text, accessibility features, etc... Unless you use case is very different from normal browser usage (e.g. 3d graphics) the advantages seem dubious to me.
- tenaciousDaniel 7y ago
  Mostly I was just curious, although I could see one argument for it. HTML/DOM was meant to display interactive documents, which is far smaller in scope than what browsers are used for today. A lot of the web today (web applications in particular) are therefore hacks of HTML. I know that the standard has responded to these uses by incorporating more application-level features, but IMO this has become burdensome and bloated. There are lots of issues coming from the fact that we're attempting to write application-level code on top of a platform that has historically been designed for documents. You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
  - klodolph 7y ago
    > You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications. Well, there are three ways to do that. You can use a 2D canvas, you can use a WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to what you get when you’re programming a desktop application anyway. This is a cornucopia of alternatives here! I’m having a hard time understanding what is missing. These “use the DOM” in the same sense that desktop applications use the window manager. You’re just drawing into an element in some compositing system. This is fine, there’s no real benefit to bypassing the DOM—like window managers, you can bypass the compositor when possible and go through the compositor when unavoidable. This is transparent to the application programmer.
    - 7y ago
marcosdumay 7y ago
Currently the DOM is the content. You can not separate those. I don't think changing this is even desirable. It's much easier and cleaner to standardize a stdlib of accessors.

klodolph 7y ago

There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code. Of course, why not just use a small HTML+JS shim for your WASM?

AnIdiotOnTheNet 7y ago
Because there is value in ditching legacy cruft.
- klodolph 7y ago
  That’s a short-term view. There’s going to be legacy cruft either way. Either we have the existing HTML + JS with WASM alongside it, or we introduce a ton of new APIs to let WASM function by itself. Using the existing HTML + JS avoids creating as much future legacy cruft.
- pdpi 7y ago
  You still capture the vast majority of that value by having a minimal “legacy cruft” loader that sets up, and passes control to, the modern toolchain
- paulhodge 7y ago
  HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.
  - weberc2 7y ago
    This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.
    - pron 7y ago
      I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
      - throwaway894345 7y ago
        I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.
        pron 7y ago
        It has not been my perception that that's an aspiration or a goal of WASM, but there's much I haven't read. Can you point me to where this is stated as one of WASM's goals?
        throwaway894345 7y ago
        https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/ > 3. Design to execute within and integrate well with the existing Web platform: > * execute in the same semantic universe as JavaScript > * access browser functionality through the same Web APIs that are accessible to JavaScript Lawyering aside, I would say that this is pretty much the same thing as "enabling the development in web apps in other languages".
- BlueTemplar 7y ago
  If you don't want cruft, don't make a browser-based app?
drfuchs 7y ago
Because it slows things down by 3 or 4 orders of magnitude?

calaphos 7y ago

You can take a Canvas element and draw anything you like on it - even hardware accelerated 3d using webGL. I think there are some projects trying to (re) implement a 2d user interface, rendered onto canvas. However the issue id that you will need to reimplement a lot of things the browser already does for you: rendering text, scaling, zoom, input methods, highlighting text, accessibility features, etc... Unless you use case is very different from normal browser usage (e.g. 3d graphics) the advantages seem dubious to me.

tenaciousDaniel 7y ago
Mostly I was just curious, although I could see one argument for it. HTML/DOM was meant to display interactive documents, which is far smaller in scope than what browsers are used for today. A lot of the web today (web applications in particular) are therefore hacks of HTML. I know that the standard has responded to these uses by incorporating more application-level features, but IMO this has become burdensome and bloated. There are lots of issues coming from the fact that we're attempting to write application-level code on top of a platform that has historically been designed for documents. You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
- klodolph 7y ago
  > You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications. Well, there are three ways to do that. You can use a 2D canvas, you can use a WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to what you get when you’re programming a desktop application anyway. This is a cornucopia of alternatives here! I’m having a hard time understanding what is missing. These “use the DOM” in the same sense that desktop applications use the window manager. You’re just drawing into an element in some compositing system. This is fine, there’s no real benefit to bypassing the DOM—like window managers, you can bypass the compositor when possible and go through the compositor when unavoidable. This is transparent to the application programmer.
  - 7y ago

marcosdumay 7y ago

Currently the DOM is the content. You can not separate those. I don't think changing this is even desirable. It's much easier and cleaner to standardize a stdlib of accessors.