Hacker News Reader

Comment by gkya | Hacker News Reader

I'm not familiar with Web Assembly, but the recent trend is that as the downloads become faster, web performance in a vanilla browser becomes slower, because websites just send more stuff to you. Pages grow toward infinity. Also, if, like @sjrd mentioned, this code can't manipulate DOM or can use only a restricted set of JS objects, the where will the gain be? Is this intended to be used for number crunching code in the browser runtime? Help bitcoin miner scripts? What's the purpose then?

View on HN

Examples of applications that require a lot of number crunching: gaming, visualization, graphics processing.

The list goes on, but the idea is that certain hot spots in an application will be able to benefit from having a fast number crunching engine.

DOM manipulation is already on the cards, should be out soon. This is likely a separate sub-team of people just working on making it as fast as possible.

Could you give details on "soon"?

All I was able to find is this issue: https://github.com/WebAssembly/design/issues/1079 with not activity for a long time

With the more recent host bindings proposal[1], direct DOM access was decoupled from GC. This is expected to move much more quickly.

[1] https://github.com/WebAssembly/host-bindings/blob/master/pro...

Running a native app compiled to wasm into the browser ? So the opposite of running an Electron app?

Calling it now:

1) Write a Windows app

2) Run it in the browser with wasm

3) Stuff that into Electron and distribute to Mac/Linux/Windows

Why distribute the electron wrapped wasm on Windows instead of using the real native Windows app? It's more consistent this way! Single codebase! Developer efficiencies!

Start here,

http://www.mono-project.com/news/2018/01/16/mono-static-weba...

Small deviation - write a native linux or mac app (instead of targeting Windows for the initial app)... mostly because I feel like developing on those platforms is so much more enjoyable.

Good point. Linux is probably the easier one because you'd need to build your UI toolkit into it and we don't have the source for Cocoa or whatever this year's Windows UI toolkit is called.

Not wasm yet, but you can definitely stick it into electron: https://bellard.org/jslinux/

I realize this is likely to be the most likely way native WASM apps are implemented because it's the most obvious to web developers, but I also think it's the wrong approach.

Webassembly.org's own docs mention that it's intended to be agnostic about its runtime environment[0]. Electron is for packaging HTML, CSS and JS into a "native" application, but WASM doesn't actually need that if it's running outside the web.

Why not a native runtime on top of a cross-platform library like SDL? Just because it's "Web Assembly" doesn't mean it has to be limited to webdev paradigms.

[0]http://webassembly.org/docs/non-web/

@sjrd is talking about limitations for JS not other languages.

C, C++, Rust and others already have their own DOM/JS support.

WASM is exciting for statically typed languages especially. JS is not the target. It might eventually benefit from faster parsing but that's not the motive now.

> C, C++, Rust and others already have their own DOM/JS support.

What does that mean? Could you expand on that?

Can Rust code compiled to wasm manipulate the DOM?

Via calling through JavaScript, yes. Wasm itself can't directly manipulate the DOM.

I'm not sure what your parent means.

Rust -- https://github.com/koute/stdweb

C++ -- https://github.com/mbasso/asm-dom

I don't know exactly how these work but Emscripten allows interop both ways (embedding JS in native code and calling native code from JS) -- https://kripken.github.io/emscripten-site/docs/porting/conne...

Reply on news.ycombinator.com