Hacker News new | ask | show | jobs
by TheAceOfHearts 3282 days ago
I think people are severely underestimating the challenges of integrating WASM with JS an DOM. Right now styling and DOM are the two biggest performance bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't terrible out of the box.

Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's IndexedDB.
1 comments
pjmlp 3282 days ago
Not really, when WebAssembly gets better it will be the revenge of Java, Flash and Silverlight.

Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

link
mvindahl 3282 days ago
There is a tradeoff between development speed and execution speed. For web apps, development speed is usually the most important of the two and the language ironing away the most technical details tends to be a strong choice.

Roughly speaking, C is further from the metal than assembly (and WASM) for obvious reasons; Java is further from the metal than C (or Rust) due to having garbage collection, and Javascript is slightly further from the metal than Java due to abstracting away threads (the gap was far wider before Java got lambdas). LISP, of course is off the scale due to abstracting away readability ;)

On a serious note, though, I don't see the advantage that Java or Flash or Silverlight would bring to web apps unless they bring greater development speed.

But I do see WASM as an excellent future supplement to JS-based apps, for optimizing time consuming parts of the code.

link
pjmlp 3281 days ago
It will be like Unity, Unreal do nowadays, and how many plugin runtimes used to do in the past.

The productivity of doing WPF/XAML development with RAD tools like Blend, using an export button to generate an WebAssembly executable.

I might be wrong, but that is where I see it going to.

link
kabes 3282 days ago
But that's already possible today without WASM. E.g. there are react plugins that render to canvas, as being used here together with some WebGL: http://www.anagram.paris/ (try to drag). And yet, we don't see this often being used. Instead, we see more DOM being used on new places (e.g. electron applications). I think if WASM+Canvas would be the way forward, we'd have already seen it by now, since it was already possible in plain JS or with asmjs if you really hate JS that much.

In the end, HTML & CSS is fast enough for most business-style applications and frameworks like angular/vue/react are pretty good ways to make frontends.

link
pjmlp 3282 days ago
Yes, but today it requires using JS or compiling into asm.js, which isn't always possible to keep the original language semantics.

WebAssembly is just yet another virtual CPU. more suitable as target for Go, .NET, Java, Flash, ....

They only need to target the framebuffer routines into Canvas/WebGL and we get desktop frameworks inside of a browser frame.

link
TheAceOfHearts 3282 days ago
Won't using Canvas or WebGL to render all content kill accessibility?
link
pjmlp 3282 days ago
Native UIs have better accessibility support than the browser.

They only need to bring them along with the plugins, to what would become a portable framebuffer.

link
ZephyrP 3281 days ago
I am totally with you on WebAssembly, but I think this is a valid point that can't be swept under the rug.

Screen-readers operating against native applications aren't even close to their utility in browsers. Easy, reasonably universal text hooking is only possible on Windows and some OSX applications and while screen-fetching is universal, it yields extremely poor results in comparison to hooking. Very popular applications occasionally build Narrarator, sythesisprompt or NDK support but today "the web" (specifically HTML) is a much, much better experience for the visually impaired.

link