Hacker News Reader

Comment by misterbowfinger | Hacker News Reader

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.

View on HN

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

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.

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.

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.

Both GCC and LLVM can compile Go code.

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 [1]: https://golang.org/doc/install/gccgo#Releases [2]: https://talks.golang.org/2014/gocon-tokyo.slide#54

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.

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

That's pretty much what it's supposed to be. Much of the browsery stuff is still supposed to be handled by JS.

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?

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.

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/

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

>language-to-js libraries

With huge performance cost and complicated toolchains.

Reply on news.ycombinator.com