Hacker News new | ask | show | jobs
by forgotpw1123 3212 days ago
... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.
3 comments

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Your comment immediately made me think of this. Highly recommended talk for anyone that hasn't seen it. It goes through a "fictional" (maybe not so much anymore) history of javascript until 2035. We are getting pretty close to javascript all the way down.

I am betting WASM will be the revenge of plugins.

And then, just like the ad spams using JS, its advocates will be getting more than they asked for.

Get ready for WASM blockers.

WASM is going to kill spidering. We can't leave HTML if we want google to be able to read the page.

I think Google is very afraid of this. Hence their push for Angular/Polymer/AMP. If they can build a good enough platform in JS they can stall the inevitable.

In the future only marketing parts of the site will use JS/HTML. The "web app" part will be some language compiled to WASM throwing frames to the canvas

In a world where SEO consultants exist, you foresee an inevitable future where Google is killed by a massive wave of companies rewriting their websites to be un-Googleable?
The big players are increasingly doing it already. LinkedIn and Facebook only have very limited spidering.

What Google has liked to do recently is take all your data and replace your service. Search for recipes, jobs, music, or weather for examples.

They're trying to make leaving the homepage irrelevant by using sites data in their search results. Eventually the web will rebel.

But management won't pay to redevelop the whole site, so they'll just embed the content in a QtWebKit widget. We can still block ads at the network level.
Sure they will.

Instead of "why I moved from Angular/React/.... to Vue.js", it will be "why I ported into WASM".

It may get there eventually, but currently, having to pass the JavaScript/wasm chasm for DOM manipulation is really slow. https://github.com/rust-webplatform/rust-webplatform/issues/...
But canvas is faster.
Canvas is part of the DOM. It is a DOM element that JS can draw graphics on.
Not a problem: you can ask the canvas for an arraybuffer to draw on, and pass that to the wasm code. I did this with asm.js in place of wasm (which didn't exist yet) in http://wry.me/hacking/Turing-Drawings/ and you can judge the speed yourself. (As that page describes, there was some overhead from calling from JS to asm.js at least when asm.js first came out. I don't know the current figures.)
asm.js is valid Javascript. It is a valid subset of js that the browser js engines understand, even for the older ones like IE 8. JavaScript has direct access to the DOM, with webassembly, not yet. It may in the future, its still in the proposal phrase (https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...)

So the way to do it today would be WebAssembly -> asm.js/js -> canvas

Good point about the proposal -- that'll be the answer in the end.

asmj.js as JS is irrelevant to the point I was making, because if you access the DOM directly, your code won't verify as the asm.js subset, and so won't run via the asm.js engine.