7 ms·

Is it safe to say, future frameworks/websites can choose to stick to HTML/CSS/WA and completely bypass JS?

gdxhyrd 7y ago
Yes, but in the far future. There are many things to be done in the standard, in the implementations, in the frameworks...
zamalek 7y ago
It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself). I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.
- Jasper_ 7y ago
  The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types https://github.com/webassembly/interface-types
  - weberc2 7y ago
    I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it. Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!
    - pcwalton 7y ago
      GC in wasm is proposed for two purposes: (1) DOM objects are garbage collected and so first-class support for them in wasm requires a GC; (2) optimal moving GC requires runtime support. A garbage collector needs to be able to walk stacks to find the root set of pointers, but the stack is hidden from the program in wasm.
    - tcard 7y ago
      In mobile code, a builtin runtime means less code to download, which may be preferable to GC performance.
- tenaciousDaniel 7y ago
  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.
- goatlover 7y ago
  > because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.
  - nerdponx 7y ago
    It's interesting that the web standardized on one programming language. In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.
    - mhink 7y ago
      Databases. Postgres supports pgSQL, Tcl, Perl, and Python out of the box, and can support others with appropriate bindings.
    - ptx 7y ago
      It doesn't seem to be in fashion these days, but some years ago language-agnostic object models for extensibility were common: Microsoft's COM, Mozilla's XPCOM, LibreOffice's UNO, IBM's SOM, etc.
    - goatlover 7y ago
      Even back inn the 90s, people were thinking of the browser as a potential OS-like platform. Netscape certainly did, and that's why MS was so worried about them.
    - int_19h 7y ago
      It's easy forget these days, but Windows had this thing called Active Scripting, that was basically a set of COM-based interfaces for scripting languages to expose their functionality OS-wide, and for apps to use any scripting language available on the system. And Internet Explorer, at the peak of its popularity, used that interface to implement the <script> tag - so long as the user had some language installed on their machine, it could be used to script web pages in IE. Active Scripting came with JavaScript and VBScript supported out of the box, which is why both were available in IE. But there were quite a few third-party ones - I recall seeing Perl, Python, Tcl, and REXX. But, of course, other browsers didn't have that. And even at the time when some websites really only cared about IE, they couldn't assume that people had any third-party runtimes installed - so you very occasionally saw VBScript, but pretty never anything else.
- cesarb 7y ago
  > It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. AFAIK, the reason the DOM and JS GC are very coupled is because there can be loops between the DOM and JavaScript: the DOM can hold JavaScript resources, which themselves can hold DOM resources. As long as these loops are avoided (by not allowing the DOM to hold resources within the WASM heap), this is not an issue.
cryptozeus 7y ago
Wsam has similar ideas like flash and silverlight but its more powerful and more open. At this point I think wsam and JS has their own place...will have to see how this plays out.
- kllrnohj 7y ago
  WASM is like the exact opposite of Flash. Flash was successful because of its ability to put things on screen. The ability to write code in it was secondary to the powerful vector graphics & animation system and the tooling around that.

Yes, but in the far future. There are many things to be done in the standard, in the implementations, in the frameworks...

zamalek 7y ago

It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself). I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.

Jasper_ 7y ago
The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem. [0] https://github.com/webassembly/interface-types https://github.com/webassembly/interface-types
- weberc2 7y ago
  I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it. Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!
  - pcwalton 7y ago
    GC in wasm is proposed for two purposes: (1) DOM objects are garbage collected and so first-class support for them in wasm requires a GC; (2) optimal moving GC requires runtime support. A garbage collector needs to be able to walk stacks to find the root set of pointers, but the stack is hidden from the program in wasm.
  - tcard 7y ago
    In mobile code, a builtin runtime means less code to download, which may be preferable to GC performance.
tenaciousDaniel 7y ago
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.
goatlover 7y ago
> because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.
- nerdponx 7y ago
  It's interesting that the web standardized on one programming language. In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.
  - mhink 7y ago
    Databases. Postgres supports pgSQL, Tcl, Perl, and Python out of the box, and can support others with appropriate bindings.
  - ptx 7y ago
    It doesn't seem to be in fashion these days, but some years ago language-agnostic object models for extensibility were common: Microsoft's COM, Mozilla's XPCOM, LibreOffice's UNO, IBM's SOM, etc.
  - goatlover 7y ago
    Even back inn the 90s, people were thinking of the browser as a potential OS-like platform. Netscape certainly did, and that's why MS was so worried about them.
  - int_19h 7y ago
    It's easy forget these days, but Windows had this thing called Active Scripting, that was basically a set of COM-based interfaces for scripting languages to expose their functionality OS-wide, and for apps to use any scripting language available on the system. And Internet Explorer, at the peak of its popularity, used that interface to implement the <script> tag - so long as the user had some language installed on their machine, it could be used to script web pages in IE. Active Scripting came with JavaScript and VBScript supported out of the box, which is why both were available in IE. But there were quite a few third-party ones - I recall seeing Perl, Python, Tcl, and REXX. But, of course, other browsers didn't have that. And even at the time when some websites really only cared about IE, they couldn't assume that people had any third-party runtimes installed - so you very occasionally saw VBScript, but pretty never anything else.
cesarb 7y ago
> It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. AFAIK, the reason the DOM and JS GC are very coupled is because there can be loops between the DOM and JavaScript: the DOM can hold JavaScript resources, which themselves can hold DOM resources. As long as these loops are avoided (by not allowing the DOM to hold resources within the WASM heap), this is not an issue.

cryptozeus 7y ago

Wsam has similar ideas like flash and silverlight but its more powerful and more open. At this point I think wsam and JS has their own place...will have to see how this plays out.

kllrnohj 7y ago
WASM is like the exact opposite of Flash. Flash was successful because of its ability to put things on screen. The ability to write code in it was secondary to the powerful vector graphics & animation system and the tooling around that.