Firefox’s new streaming and tiering compiler

Re:Firefox’s new streaming and tiering compiler by gkya on Wednesday January 17, 2018 @12:28PM (#16169807)

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?

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by yzmtf2008 on Wednesday January 17, 2018 @12:40PM (#16169955)

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.

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by sudhirj on Wednesday January 17, 2018 @01:26PM (#16170364)

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.

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by pas on Thursday January 18, 2018 @06:48AM (#16176404)

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

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by linclark on Thursday January 18, 2018 @02:50PM (#16180680)

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...

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by seren on Wednesday January 17, 2018 @12:35PM (#16169886)

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

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by wlesieutre on Wednesday January 17, 2018 @01:32PM (#16170423)

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!

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by swsieber on Wednesday January 17, 2018 @02:50PM (#16171151)

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.

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by wlesieutre on Wednesday January 17, 2018 @04:55PM (#16172373)

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.

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by pjmlp on Wednesday January 17, 2018 @01:42PM (#16170524)

Start here,

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

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by krapp on Wednesday January 17, 2018 @06:31PM (#16173090)

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/

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by viraptor on Wednesday January 17, 2018 @03:35PM (#16171537)

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

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by logn on Wednesday January 17, 2018 @04:12PM (#16171872)

@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.

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by pas on Thursday January 18, 2018 @06:49AM (#16176409)

> 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?

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by logn on Thursday January 18, 2018 @01:11PM (#16179638)

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...

[ Parent | on HN ]

Re:Firefox’s new streaming and tiering compiler by steveklabnik on Thursday January 18, 2018 @08:46AM (#16176969)

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

I'm not sure what your parent means.

[ Parent | on HN ]