So is the JS runtime. So why don't we just write apps in raw WASM?
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.
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?
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/
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.
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/structu...
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) {
There's currently no standard. If there's a will, there's a way.
JSON+LD is the standard for JavaScript based metadata.
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.
Don't know about screen readers. I'd be surprised if they weren't using the live DOM, though.
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.
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?
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?
My point was that yes, VDOM has overhead. But we accept it as a tradeoff for app development in the name of DevX.
Anyway, another idea is to ditch the entire DOM and render on the canvas.