5 ms·

Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're re

Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm. Yes I realize I'm essentially advocating for jquery with java applets, but it could really work this time! (I think a lot of the issues originally were political) Make htmx like attributes part of the HTML spec, keep working on web components. Still don't know why web components haven't taken off.

randomdata 4y ago
> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?
- CharlieDigital 4y ago
  Short answer: yes. Crawlers are based on consuming text. HTML is text. Sites that optimize for SEO also use JavaScript to provide SEO context. The specific standard is called JSON+LD; pretty much any site that you use where SEO matters has JSON+LD, RDF-a, or Microdata embedded in the HTML. You can see these structures if you use the Schema.org validator: https://validator.schema.org/ https://validator.schema.org/ Try plugging in a URL like Reddit.com and see for yourself. On e-commerce websites, it's a *must have*. For example, try this Amazon page: https://www.amazon.com/dp/B09V3GZD32 https://www.amazon.com/dp/B09V3GZD32. TL;DR: crawlers are parsing RDF-a and Microdata in the HTML or JSON+LD embedded in `<script/>` tags. You can learn more about it here: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data https://developers.google.com/search/docs/appearance/structu...
  - randomdata 4y ago
    Here's an excerpt of some Javascript found on the Amazon link: window.ue_ihb = (window.ue_ihb || window.ueinit || 0) + 1; if (window.ue_ihb === 1) { var ue_csm = window, ue_hob = +new Date(); (function(d) { var e = d.ue = d.ue || {}, f = Date.now || function() { return +new Date }; e.d = function(b) { return f() - (b ? 0 : d.ue_t0) }; e.stub = function(b, a) { Feel free to visit it to find the entire script. It is much too large to post here. What is a crawler learning from that program that would be lost if the equivalent code was bundled as WASM instead? Why couldn't its WASM parser pull out the same information? The JS/WASM runtime in the browser has to produce the same result regardless of which encoding is chosen, so everything will be encoded in there somehow.
    - CharlieDigital 4y ago
      > Why couldn't its WASM parser pull out the same information There's currently no standard. If there's a will, there's a way. JSON+LD is the standard for JavaScript based metadata.
      - randomdata 4y ago
        I don't get it. JSON+LD is not Javascript. It's not even spelled the same? If you are meaning that your Javascript is able to read JSON+LD, so too could you WASM in this hypothetical world we're talking about.
        CharlieDigital 4y ago
        JSON is literally JavaScript Object Notation, my friend.
        randomdata 4y ago
        Which, humorously, isn't compatible with Javascript object notation. { foo: "bar" } is a valid Javascript object, but not valid JSON. Regardless, I don't get what you are trying to say. Pretty much every language still in existence is able to work with JSON (even SQL!). JSON is not Javascript. It's not clear why moving code from the Javascript runtime to the WASM runtime would magically make JSON+LD inoperable or whatever it is you are trying to say.
- mrtranscendence 4y ago
  No, as far as I know they render the page as part of the crawling. I'm not a web developer but I don't see why that couldn't be done with WASM. Don't know about screen readers. I'd be surprised if they weren't using the live DOM, though.
- traverseda 4y ago
  I presumed that you were talking about replacing the HTML with a wasm-rendered app, if you're just talking about replacing javascript with compiled javascript blobs, well we already do that general type of transpilation using tools like babel.
  - randomdata 4y ago
    The original comment wasn't mine, but there was no mention of HTML anywhere. Where did that come from?
    - traverseda 4y ago
      99% of the time WASM is being used right now it isn't being used to manipulate the DOM, and last time I checked the actual DOM bindings for WASM didn't really work. There was no mention of HTML and right now no one is using WASM for html, so I assumed GP meant normal WASM type stuff, not theoretical WASM-dom bindings that I haven't seen anyone use yet.
      - randomdata 4y ago
        > 99% of the time WASM is being used right now it isn't being used to manipulate the DOM Almost certainly. I would expect that 50% of WASM being used right now is outside of the browser entirely. Cloudflare Workers, for example. Same goes for Javascript. Regardless, I expect the real serious answer is that writing raw WASM isn't particularly ergonomic. You could do it if you had to, but it is very much designed to be a compiler target. The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation. Reading the article he would have realized that Svelte offers much the same without a virtual DOM, and that the headline refers to that, but when was the last time anyone on HN read the article?
        traverseda 4y ago
        > The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation. Were they? Alternative interpretations abound. "Raw WASM" implies that they were sarcastically saying the virtual DOM makes things a whole lot easier, and if all you care about is performance you might as well hand write a bunch of assembly. Another interpretation would be that the whole DOM is inefficient, so you might as well transpile some kind of native toolkit to a WASM engine. There are a lot of different interpretations for that pithy sentence. Does raw mean written by hand or does it mean not using DOM bindings?
- postalrat 4y ago
  WASM doesn't access anything without javascript. (in a browser)

randomdata 4y ago

> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?

CharlieDigital 4y ago
Short answer: yes. Crawlers are based on consuming text. HTML is text. Sites that optimize for SEO also use JavaScript to provide SEO context. The specific standard is called JSON+LD; pretty much any site that you use where SEO matters has JSON+LD, RDF-a, or Microdata embedded in the HTML. You can see these structures if you use the Schema.org validator: https://validator.schema.org/ https://validator.schema.org/ Try plugging in a URL like Reddit.com and see for yourself. On e-commerce websites, it's a *must have*. For example, try this Amazon page: https://www.amazon.com/dp/B09V3GZD32 https://www.amazon.com/dp/B09V3GZD32. TL;DR: crawlers are parsing RDF-a and Microdata in the HTML or JSON+LD embedded in `<script/>` tags. You can learn more about it here: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data https://developers.google.com/search/docs/appearance/structu...
- randomdata 4y ago
  Here's an excerpt of some Javascript found on the Amazon link: window.ue_ihb = (window.ue_ihb || window.ueinit || 0) + 1; if (window.ue_ihb === 1) { var ue_csm = window, ue_hob = +new Date(); (function(d) { var e = d.ue = d.ue || {}, f = Date.now || function() { return +new Date }; e.d = function(b) { return f() - (b ? 0 : d.ue_t0) }; e.stub = function(b, a) { Feel free to visit it to find the entire script. It is much too large to post here. What is a crawler learning from that program that would be lost if the equivalent code was bundled as WASM instead? Why couldn't its WASM parser pull out the same information? The JS/WASM runtime in the browser has to produce the same result regardless of which encoding is chosen, so everything will be encoded in there somehow.
  - CharlieDigital 4y ago
    > Why couldn't its WASM parser pull out the same information There's currently no standard. If there's a will, there's a way. JSON+LD is the standard for JavaScript based metadata.
    - randomdata 4y ago
      I don't get it. JSON+LD is not Javascript. It's not even spelled the same? If you are meaning that your Javascript is able to read JSON+LD, so too could you WASM in this hypothetical world we're talking about.
      - CharlieDigital 4y ago
        JSON is literally JavaScript Object Notation, my friend.
        randomdata 4y ago
        Which, humorously, isn't compatible with Javascript object notation. { foo: "bar" } is a valid Javascript object, but not valid JSON. Regardless, I don't get what you are trying to say. Pretty much every language still in existence is able to work with JSON (even SQL!). JSON is not Javascript. It's not clear why moving code from the Javascript runtime to the WASM runtime would magically make JSON+LD inoperable or whatever it is you are trying to say.
mrtranscendence 4y ago
No, as far as I know they render the page as part of the crawling. I'm not a web developer but I don't see why that couldn't be done with WASM. Don't know about screen readers. I'd be surprised if they weren't using the live DOM, though.
traverseda 4y ago
I presumed that you were talking about replacing the HTML with a wasm-rendered app, if you're just talking about replacing javascript with compiled javascript blobs, well we already do that general type of transpilation using tools like babel.
- randomdata 4y ago
  The original comment wasn't mine, but there was no mention of HTML anywhere. Where did that come from?
  - traverseda 4y ago
    99% of the time WASM is being used right now it isn't being used to manipulate the DOM, and last time I checked the actual DOM bindings for WASM didn't really work. There was no mention of HTML and right now no one is using WASM for html, so I assumed GP meant normal WASM type stuff, not theoretical WASM-dom bindings that I haven't seen anyone use yet.
    - randomdata 4y ago
      > 99% of the time WASM is being used right now it isn't being used to manipulate the DOM Almost certainly. I would expect that 50% of WASM being used right now is outside of the browser entirely. Cloudflare Workers, for example. Same goes for Javascript. Regardless, I expect the real serious answer is that writing raw WASM isn't particularly ergonomic. You could do it if you had to, but it is very much designed to be a compiler target. The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation. Reading the article he would have realized that Svelte offers much the same without a virtual DOM, and that the headline refers to that, but when was the last time anyone on HN read the article?
      - traverseda 4y ago
        > The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation. Were they? Alternative interpretations abound. "Raw WASM" implies that they were sarcastically saying the virtual DOM makes things a whole lot easier, and if all you care about is performance you might as well hand write a bunch of assembly. Another interpretation would be that the whole DOM is inefficient, so you might as well transpile some kind of native toolkit to a WASM engine. There are a lot of different interpretations for that pithy sentence. Does raw mean written by hand or does it mean not using DOM bindings?
postalrat 4y ago
WASM doesn't access anything without javascript. (in a browser)