WebAssembly’s post-MVP future

Re:WebAssembly’s post-MVP future by edflsafoiewq on Tuesday October 23, 2018 @12:00AM (#18280627)

If they're not even portable between established systems, how are we going to port them to a comparatively exotic wasm+DOM target?

[ Parent | on HN ]

Re:WebAssembly’s post-MVP future by pjmlp on Tuesday October 23, 2018 @02:57AM (#18281288)

Because it is actually WASM + Canvas, DOM doesn't matter.

http://example.qt.io/qt-webassembly/quickcontrols2/gallery/g...

https://playground.platform.uno/

[ Parent | on HN ]

Re:WebAssembly’s post-MVP future by edflsafoiewq on Tuesday October 23, 2018 @03:11AM (#18281355)

Wasm+canvas is an easier target but even if it gets us to the same difficulty as normal desktop targets, portability between normal targets is already a problem.

My reaction to using the canvas instead of the DOM is very, very, very negative by the way. Webpages with fake text that is actually pixels rendered to a canvas are currently mostly restricted to dystopian notions of either the end result of the ad-blocker arms race or else extreme anti-copying measures.

[ Parent | on HN ]

Re:WebAssembly’s post-MVP future by pjmlp on Tuesday October 23, 2018 @03:15AM (#18281375)

Basically it is Flash all over again, just now it is built-in in the browser.

[ Parent | on HN ]

Re:WebAssembly’s post-MVP future by mcl7cdm on Wednesday October 24, 2018 @03:29AM (#18290367)

I think the world MUST start to make/tell the difference between (web)apps and web pages. Slack does not need to be written in js/html. Skype does not need to be written in js/html. They do those in electron just to avoid having to maintain X different code bases.

[ Parent | on HN ]