5 ms·

Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage who

Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.

Dayshine 9y ago
>language-to-js libraries With huge performance cost and complicated toolchains.
wvenable 9y ago
WebAssembly allows you to build "native" libraries that can be accessed from JavaScript. There is huge value in that.
deleted 9y ago
[deleted]
cjfont 9y ago
So there's a lot of other things that can be done on the client other than interacting with the DOM. In particular, applications that render intense graphics, or manage a local database could GREATLY benefit from more efficient compiled code, and this would open up possibilities that the current JS engine wouldn't be able to deliver.
- littlestymaar 9y ago
  That's indeed true, but I wouldn't count Go as an example of “efficient compiled code”. It's way behind of GCC or LLVM in terms of optimizations, and being ahead-of-time-compiled is a drawback, not an asset.
  - mappu 9y ago
    Both GCC and LLVM can compile Go code.
    - littlestymaar 9y ago
      That's a bit of an oversimplification. About llvm, there's a WIP prototype that doesn't quite work yet[0]. And about GCC, GccGo is behind in Go's version. GCC 7 only supports Go 1.8 (with caveats). Also, it had issues at some point[2] (but this is from 2014, it may have been fixed since then). And, on a more pragmatic point of view, when talking about Go, the huge majority talks about Go compiled with the standard Go compiler. That's why you here a lot of positive feedback about compile-times for instance. [0]: http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT [1]: https://golang.org/doc/install/gccgo#Releases https://golang.org/doc/install/gccgo#Releases [2]: https://talks.golang.org/2014/gocon-tokyo.slide#54 https://talks.golang.org/2014/gocon-tokyo.slide#54
strkek 9y ago
As weird as this might sound, I see WebAsssembly more like a portable shared library format than a JavaScript replacement.
- solarkraft 9y ago
  That's pretty much what it's supposed to be. Much of the browsery stuff is still supposed to be handled by JS.
- e12e 9y ago
  On a related note: does anyone know if there's wasm support with ocaml/reasonml? It seems running reasonml/ocaml under nodejs with wasm (and in the browser) should be a great fit for ocaml modules?
dangerbird2 9y ago
Webassembly uses a javascript "glue" for accessing the DOM. The point of Webassembly is not to just be an alternative to javascript; it's to have a binary web program format that runs at close to native speeds. This makes it extremely useful for porting C/C++ applications, especially games, to the browser.
tyingq 9y ago
DOM access is planned. https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079. (first bullet point)
caspervonb 9y ago
WebAssembly actually CAN access the DOM, but it requires some glue code. Essentially, from the developer perspective WebAssembly is like embedding native code as a scripting language in the browser. Only primitive data types can be passed back and forth between the foreign function interface between the two.
slashink 9y ago
Twitch rewrote their entire video player in C++ and compiles it down to WebAssembly with Emscripten. That way the same player can be compiled to the web, as to iOS, Android, game consoles etc. That’s a huge business case when you want to create a module to support a wide variety of platforms and targets.
irascible 9y ago
You can call in and out of webassembly to js to manipulate the dom if that's your thing.
sp332 9y ago
It can be a lot faster and less memory-hungry than javascript. That opens up a lot of things you can't feasibly do in JS. Game engines, image decoding, even video editing. http://webassembly.org/docs/use-cases/ http://webassembly.org/docs/use-cases/

Dayshine 9y ago

>language-to-js libraries With huge performance cost and complicated toolchains.

wvenable 9y ago

WebAssembly allows you to build "native" libraries that can be accessed from JavaScript. There is huge value in that.

deleted 9y ago

[deleted]

cjfont 9y ago

So there's a lot of other things that can be done on the client other than interacting with the DOM. In particular, applications that render intense graphics, or manage a local database could GREATLY benefit from more efficient compiled code, and this would open up possibilities that the current JS engine wouldn't be able to deliver.

littlestymaar 9y ago
That's indeed true, but I wouldn't count Go as an example of “efficient compiled code”. It's way behind of GCC or LLVM in terms of optimizations, and being ahead-of-time-compiled is a drawback, not an asset.
- mappu 9y ago
  Both GCC and LLVM can compile Go code.
  - littlestymaar 9y ago
    That's a bit of an oversimplification. About llvm, there's a WIP prototype that doesn't quite work yet[0]. And about GCC, GccGo is behind in Go's version. GCC 7 only supports Go 1.8 (with caveats). Also, it had issues at some point[2] (but this is from 2014, it may have been fixed since then). And, on a more pragmatic point of view, when talking about Go, the huge majority talks about Go compiled with the standard Go compiler. That's why you here a lot of positive feedback about compile-times for instance. [0]: http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT [1]: https://golang.org/doc/install/gccgo#Releases https://golang.org/doc/install/gccgo#Releases [2]: https://talks.golang.org/2014/gocon-tokyo.slide#54 https://talks.golang.org/2014/gocon-tokyo.slide#54

strkek 9y ago

As weird as this might sound, I see WebAsssembly more like a portable shared library format than a JavaScript replacement.

solarkraft 9y ago
That's pretty much what it's supposed to be. Much of the browsery stuff is still supposed to be handled by JS.
e12e 9y ago
On a related note: does anyone know if there's wasm support with ocaml/reasonml? It seems running reasonml/ocaml under nodejs with wasm (and in the browser) should be a great fit for ocaml modules?

dangerbird2 9y ago

Webassembly uses a javascript "glue" for accessing the DOM. The point of Webassembly is not to just be an alternative to javascript; it's to have a binary web program format that runs at close to native speeds. This makes it extremely useful for porting C/C++ applications, especially games, to the browser.

tyingq 9y ago

DOM access is planned. https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079. (first bullet point)

caspervonb 9y ago

WebAssembly actually CAN access the DOM, but it requires some glue code. Essentially, from the developer perspective WebAssembly is like embedding native code as a scripting language in the browser. Only primitive data types can be passed back and forth between the foreign function interface between the two.

slashink 9y ago

Twitch rewrote their entire video player in C++ and compiles it down to WebAssembly with Emscripten. That way the same player can be compiled to the web, as to iOS, Android, game consoles etc. That’s a huge business case when you want to create a module to support a wide variety of platforms and targets.

irascible 9y ago

You can call in and out of webassembly to js to manipulate the dom if that's your thing.

sp332 9y ago

It can be a lot faster and less memory-hungry than javascript. That opens up a lot of things you can't feasibly do in JS. Game engines, image decoding, even video editing. http://webassembly.org/docs/use-cases/ http://webassembly.org/docs/use-cases/