5 ms·

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. F

> Web Assembly is not meant to be a replacement for JavaScript. This seems like a very short sighted view. It's meant to offer options other than JavaScript. For many of us who dislike JS, this is exactly what webassembly represents, a way to deploy applications without JavaScript to the browser, in effect finally achieving the full dream of the JVM. And yes, DOM integration isn't there right now, but it will be. It makes sense to me that this is initially being limited for a number of reasons. It definitely means people won't immediately glob onto it, reducing the potential of accidentally locking in implementation bugs/features. Some people think the DOM is unnecessary even in a webassembly world, but I think CSS and the DOM are generally good, what I've always wanted is a better language option. I'm practically giddy with the potential for all of this finally happening!

couchand 9y ago
I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS. That being said, I hope I'm proven wrong.
zurn 9y ago
JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.
TheAceOfHearts 9y 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.
- pjmlp 9y 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.
  - kabes 9y 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/ 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.
    - pjmlp 9y 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.
  - TheAceOfHearts 9y ago
    Won't using Canvas or WebGL to render all content kill accessibility?
    - pjmlp 9y 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.
      - 9y ago
rubber_duck 9y ago
I don't think you should even aim for DOM integration, DOM sucks for apps, having to go trough JS bridge when you need to use it is fine. I would be much happier if they exposed APIs such as WebGL, user input, IO, etc. to WASM trough WASM specific APIs than wrapping JS ones (but doubt they will do it)

couchand 9y ago

I'm excited but I'm also cautious. I'm not sure that WASM has a slam dunk story in terms of many web-native concepts, for instance asynchronous execution. The browser APIs will likely lag far behind JS, and DOM integration is just one thing there - also fetch, indexeddb/localstorage, and so forth. WASM gives us some additional tools for the web toolbelt, but it will be a long, long time before it's mature enough to completely replace JS. That being said, I hope I'm proven wrong.

zurn 9y ago

JS is a much better compile target for many languages for the foreseeable future. "Without JS" is not a sensible end in itself.

TheAceOfHearts 9y 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.

pjmlp 9y 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.
- kabes 9y 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/ 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.
  - pjmlp 9y 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.
- TheAceOfHearts 9y ago
  Won't using Canvas or WebGL to render all content kill accessibility?
  - pjmlp 9y 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.
    - 9y ago

rubber_duck 9y ago

I don't think you should even aim for DOM integration, DOM sucks for apps, having to go trough JS bridge when you need to use it is fine. I would be much happier if they exposed APIs such as WebGL, user input, IO, etc. to WASM trough WASM specific APIs than wrapping JS ones (but doubt they will do it)